David Mclachlan 25Q_92% Agile Att 01 Flashcards
PMP PREP - MOC
You have been completing small, usable increments of value as part of your Agile team. When reporting back to the project sponsor of this project, the last iteration is referred to as a “fast failure.” What does this mean?
a- The iteration did not complete all the story cards in the allotted time.
b- The project team found a bug in the code before delivery.
c- The proof-of-concept for that iteration did not have the intended outcome.
d- The product backlog was not groomed in time to start the next iteration.
> Agile operates on the concept of delivering increments of value.
Fast failure means that particular feature or proof-of-concept effort was not successful. By failing fast and in small increments, the project team is able to learn and adjust quickly and at a much lower cost.
You are in the forming stages of a new project team, and deciding on the way of work to use when operating as a team. What are some of the factors that will influence how you tailor the project lifecycle?
- The demand pattern for value or delivery: is it steady or sporadic?
- The rate of process improvement required by the team.
- Is more than one team is needed to build the product?
- All of the above.
Project lifecycles or ways of working can be influenced by many factors – in fact almost everything will impact this decision : The way the organisation works, whether the work is certain or uncertain, whether the features are subject to change, what has worked before and what the team is comfortable with all play a part.
The product owner has worked with the development team to list all work to be done, write up user stories for each feature and place them in the product backlog. What will you do next?
- Refine the backlog to ensure only important items are being worked on.
- Create the schedule management plan to ensure you know when each item can be delivered.
- Sort the items by business priority, place them in an iteration, complete the items then remove them from the backlog.
- Move the items into the requirements traceability matrix so you can report on their progress.
Managing the project requirements via the product backlog is a fundamental Agile practice. The product backlog is the source of truth, and is continuously re-prioritised as the work gets done to ensure maximum value is delivered first.
The business partner or product owner continuously refines, or grooms, the product backlog. This includes adding new stories, reprioritizing stories, and removing stories when needed. What role does the development team take during this process?**
- Developing the cards as soon as they are added to ensure maximum value.
- Removing cards from the backlog that do not make sense to complete.
- Estimating the work needed for each card so the product owner can prioritise based on value and effort.
- Coming to daily stand-ups to report on what was done yesterday and what will be done today.
During backlog grooming the development team is responsible for sizing or estimating the work. This allows the product owner, business representative or customer to prioritise effectively, based on value and time to delivery.
You have been estimating story cards with your Agile project team, but the effort captured has not been matching the time it ends up taking to complete. What is the most likely reason for this occurring?
- The team have not included sick days in the estimate.
- The team have not included testing or refactoring in the estimate.
- The team have not included time to merge the code for continuous integration.
- The team have not included the time it takes for the daily stand-up.
Estimates for story cards should include all known activities required to complete that card, including testing and refactoring, complexity and risk.
You are working through the backlog with the product owner and estimating the story cards with the development team. The team have never worked on a product like this before and are unsure if their estimates are accurate enough. What will you recommend they use?
- Affinity estimating, using actual effort from a similar feature on a different project.
- T-shirt sizing, using broad Small, Medium or Large sizes to accommodate variation.
- Three point estimating, where the team gives the average of an optimistic, pessimistic and most likely estimate.
- The product owner should estimate the story cards as they are getting the benefit of the delivered features.
While most estimation methods will do, the best one in this case is Affinity estimating, using a similar example from a previous project.
Agile estimating is most often done by breaking down the features into small tasks, then estimating on those tasks (bottom-up).
!!!!! Where that doesn’t work, Affinity estimating will fill in the blanks. !!!!!
You are delivering features through your Agile project and the project sponsor and product owner are happy with the progress. Your project sponsor raises a concern about future items and what that development looks like. What will you show them?
- The Project Management Plan, that has outlined the project delivery in full.
- The product backlog, that has the list of features the team will deliver.
- The product roadmap, that shows planned future features and their approximate dates, similarly to a Gantt Chart.
- The team velocity chart, that shows how much the team completes each iteration.
A product roadmap is a visual display of the product releases, similar to a Gantt Chart or project schedule but based around Agile feature releases.
It is a high level view and revised as necessary.
There are four main lifecycle approaches to managing a project, with variations in between. What is one of the characteristics of an “Iterative” lifecycle approach?
- It does not need feedback for work in progress to reduce that work in progress.
- It allows feedback for unfinished work to improve and modify that work.
- It focuses on delivery, not feedback.
- It plans the project up front and delivers in one go.
An Iterative project lifecycle “iterates” towards success.
It uses prototypes and unreleased versions of the product to gather feedback and improve before releasing it.
You are the Agile lead or Scrum Master for your Agile team and planning for the next iteration is about to begin. What will you do first?
- Break down the features into user stories.
- Write the story card acceptance criteria with the team.
- Choose which stories the team will work on in the iteration.
- Work with the product owner to prioritises the highest value ones to work on.
During iteration planning the team should have already broken down features into story cards.
Now is the time to reprioritise the cards that can be done based on the — business value and the team velocity — (what can be completed).
You are working with your Agile project team to estimate each task and how long they might take. The team is finding it difficult to give an exact figure, and worries that it might impact project delivery. What can you show them, to estimate more accurately?
- Ask them to estimate by whole iteration to give a little room for variation.
- Estimate the cards in full days instead of effort per card.
- Use comparative estimates or relative sizing such as T-shirt sizing or story points.
- Prioritise the backlog based on customer value.
A common Agile practice is to rely on relative sizing such as story points or “T-Shirt sizing.” Team velocity is then measured using those same methods as the team completes a certain amount of points per iteration. This is easier than trying to predict an exact time period.
You are working through a sprint planning meeting with your team. The team have sized up the cards and prioritised the backlog. What will you do next to determine how much work can be done during this iteration?
- Count up the user stories that the product owner wants completed by the end of the iteration.
- Check the team’s velocity against the number of points for the story cards you want to complete.
- Ask the Scrum Master to allocate work to each team member in the fairest manner possible.
- Look at other teams and what they did in the last iteration to give the best idea for your team.
Velocity is the amount of work (measured by points, hours, cards or anything you wish) a team completes on average in a given sprint.
By checking the total points for the cards you wish to complete against what is possible via the team velocity, you will know what is possible and can adjust as necessary.
You are the Agile project manager working on a software project, and the development team have identified a major risk for the delivery of a certain feature. That feature is not scheduled until very late in the project. What will you do next?
- Wait until later in the project, as the problem may be fixed by other features going in.
- Ask the developers to find a way to proceed without that feature.
- Plan a spike around the risk, identify a solution then prioritise that feature earlier in development.
- Remove all other story cards from the current sprint so the team can swarm around the issue and fix it.
Agile risks are prioritised early in development, to reduce and remove those risks.
Discovery work is typically done with a spike card, but does not need to be done by the whole team.
Allocate a certain amount of time to it, then prioritise the risk early so it is taken care of and you know what you are dealing with.
Scrum is a single-team framework for managing product development. There are certain events, ceremonies and roles and responsibilities within a Scrum team. Which of the below is NOT a role or responsibility in a Scrum team?
- Product Owner, representing the customer and responsible for maximising the value of the product.
- Development Team, developing and testing the product, cross functional, self-organising with all the roles needed to deliver the product.
- Scrum Master, ensuring the Scrum processes such as stand-ups and retrospectives, coaching the team and removing blockers.
- Risk Manager, capturing and reviewing risks and ensuring each one has an assigned owner.
Risk and Quality are the responsibility of the whole team in an Agile way of work, and so typically a single person is not responsible for it.
The product owner ensures the right features are delivered
The development team ensures the code is refactored regularly
The Scrum Master ensures the team process is improved over time
and the Quality tester ensures features are free of defects.
