Listen to this post:
This is part 5 of 7 posts on PMI-ACP Exam Prep (link to part 4). In this post, I focus on sizing, estimating, and planning, including adaptive planning, progressive elaboration, value-based analysis and decomposition, and release/iteration planning.
Agile projects call for adaptive planning. An adaptive approach acknowledges that planning is an ongoing process and provides multiple mechanisms to proactively update the plan. This is what distinguishes agile planning from a more predictive, static approach in which most of the plan is created up front and replanning is done primarily in response to exceptions to the plan and change requests.
To help organize this post, I’ll group topics into 3 groups: agile planning concepts, tools for sizing and estimating, and the process of release and iteration planning.
Agile Planning Concepts
As discussed in previous posts, agile methods are value-driven – they aim to maximize the delivery of business value. This is why the backlog is prioritized with high business value items at the top and why releases aim to maximize the value of the functionality being delivered.
The only way to be successful at agile projects is to plan to replan. This is based on the conscious acceptance that early plans are both necessary and likely to be flawed; therefore, replanning and adaptation activities should be scheduled into the project. Uncertainty drives the need to replan.
Agile vs. Non-Agile Planning
Agile planning differs from traditional planning in 3 key ways:
- Trial and demonstration uncover the true requirements, which then require replanning.
- So instead of creating very detailed specifications and plans, agile projects build a prototype to better understand the domain and use this prototype as the basis for future planning and elaboration.
- Agile planning is less of an up-front effort and is instead done throughout the project.
- Agile methods recognize that the level of risk and uncertainty on knowledge work projects makes extensive up-front planning problematic, so they distribute the planning effort throughout the project’s lifecycle.
- Midcourse adjustments are the norm.
- Planning occurs on agile projects first with a high-level plan, and then at regular points throughout the project for subsequent release and iterations. Agile teams also factor a lot of feedback into these ongoing planning processes. For example:
- Backlog reprioritization effects iteration and release plans.
- Feedback from iteration demonstrations generates product changes and new requirements.
- Retrospectives generate changes to the team’s processes and techniques.
- Planning occurs on agile projects first with a high-level plan, and then at regular points throughout the project for subsequent release and iterations. Agile teams also factor a lot of feedback into these ongoing planning processes. For example:
Make no mistake, the total amount of planning on agile projects is more than traditional projects. It’s just that the planning activities are distributed differently throughout the project life cycle.
Principles of Agile Planning
Let’s look at some high-level principles for agile planning.
- Plan at multiple levels.
- At a high level, we plan the overall scope and what “done” looks like for the project. We plan releases and a little more detail, painting the map of which features we would like delivered when. We didn’t plan the iterations in even more detail, identifying which stories will be built in each iteration, and planning the tasks needed to complete them.
- Engage the team and the customer in planning.
- It’s unlikely that a leader or the manager will have all the information required to satisfy customer’s needs. So we have to engage both the team and customer in planning. This will take advantage of the team’s knowledge and technical insights and also generate their plan and commitment for the plan that is developed so that we don’t have to sell it to them afterward.
- Manage expectations by frequently demonstrating progress and extrapolating velocity.
- Agile teams shown what has been built as the process goes along. Keeping stakeholders up to speed on what is happening and managing their expectations.
- Tailor processes to the project’s characteristics.
- Large projects will need more planning and small projects. If there are a lot of uncertainties, the team will need to plan for spikes to explore options and confirm that the proposed technological approach will work.
- Update the plan based on the project’s priorities.
- The business sets the project priorities, and these are reflected in the backlog priorities created by the product owner, in collaboration with the development team.
- Ensure encompassing estimates that account for risk, distractions, and team availability.
- Use appropriate estimate ranges to reflect the level of uncertainty in the estimate.
- base projections on completion rates.
- Factor in diversions and outside work.
The concept of “agile discovery” is an umbrella term that refers to the evolution and elaboration of an agile project plan in contrast with an up-front, traditional approach to project planning. It covers topics such as:
- Emergent plans and design vs. predictive plans and designs
- Preplanning activities to gather consensus on the best approach to follow
- backlog refinement (grooming) and how it is performed
- Estimating uncertain work vs. certain work
- The characteristics of new product development vs. well-understood and repeatable projects
Progressive elaboration refers to the process of adding more detail as new information emerges. At the beginning of a project, the team needs to size and estimate the work involved to determine how big the endeavor is likely to be and to create a reasonable strategy and execution approach. However, the beginning of a project is when we know the least about the endeavor. So we must continually refine our plans and estimates as the project progresses and new details emerge. This process of continual updates is the essence of progressive elaboration.
Progressive Elaboration vs. Rolling Wave Planning
Rolling wave planning is PMI’s term for the strategy of planning at multiple points in time as more information about the project becomes available. Rolling wave planning is the game plan that says we won’t try to do all our planning up front. We recognize that it will be better to plan a bit, and then revisit and update our plan multiple time throughout the project.
Progressive elaboration is what we do to incorporate new information into our plans s we progress with the project. It is how we implement the rolling wave panning approach.
Agile planning is based on a value-based analysis. To fully understand an item’s value, we also need to understand its development and delivery cost. For example, the feature that is worth $5000 to the business but costs $4000 dollars to develop is not as valuable as something that delivers $3000 dollars in value to the business and only costs $1000 to develop.
Therefore, when validating the value of a work item, we need to factor in its likely development cost. In order to do that, agile teams will create high-level estimates of the backlog items early in the project. This allows them to make cost-benefit value comparisons that the customer can use to prioritize items for development. For example, to maximize the value delivered in the next release, the team may plan to complete several medium value features that they can develop quickly rather than one higher value items that would consume all the remaining development time.
Two other factors that need to be considered are payback frequency and dependencies:
- Will the work item generate business value every week or month or just wants?
- Sometimes a high business value item is dependent on a low business value item. In that case, the team will need to undertake the low business value items first, to allow them to deliver the high business value items as soon as possible.
With these considerations in mind, the team and the customer will analyze the real business value of features, prioritize the features appropriately, and plan the work.
The first step in this process will be some kind of effort to define the vision. The team elicits requirements from stakeholders; groups, breaks down and ranks those requirements; and then pulls the prioritized requirements into the development process. A product backlog is created and the agile process of planning each sprint and iteration gets underway.
Agile methods don’t attempt to specify fully detailed requirements up front. Instead, we initially keep the requirements “coarse-grained”, and then progressively refine them as the planning process continues. This approach has a number of advantages:
- It helps keep the overall design balanced so the product doesn’t become lopsided by overdevelopment in any particular area.
- It delays decisions on implementation details until the “last responsible moment.” This means we are nor rushing to develop things that may later need to be changed ass a result of new information or late-breaking change requests.
A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal. Rather than allow work to continue until the goal is reached, and evaluating the time taken, the timebox approach consists of stopping work when the time limit is reached and evaluating what was accomplished.
All five events in Scrum are timeboxed:
Sprint: Timeboxing is used to define the length of the Sprint. The Sprint is a timebox of one month or less in which the scrum team will deliver the Sprint goals. It is recommended that you keep Sprint timebox to one week.
Sprint Planning: When a team launches, they establish the timebox for the Sprint Planning meeting. A Sprint planning meeting should be timeboxed at 8 hours or less for a one-month Sprint. The shorter the Sprint, the shorter the timebox should be for Sprint Planning. It is recommended that you have one-week Sprints and a two-hour timebox for Sprint Planning.
Daily Scrum: The Daily Scrum is a timebox of 15 minutes for each 24-hour period that helps the Scrum Team synchronize activities and make visible any impediments to achieving the Sprint Goal.
Sprint Review: The Sprint Review is a timebox of four hours or less for one-month Sprints. During the Sprint Review, Sprint Backlog items delivered during the sprint are demonstrated and inspected. It is also a time to adapt the backlog based on feedback.
Sprint Retrospectives: The Sprint Retrospective is a timebox of three hours or less for a one month sprint. This is an event in which the team inspects itself and identifies a process improvement that the team will implement in the following sprint.
Estimating work effort in agile projects is fundamentally different from traditional methods of estimation. The traditional approach is to estimate using a “bottom-up” technique: detail out all requirements and estimate each task to complete those requirements in hours/days, then use this data to develop the project schedule. Agile projects, by contrast, use a “top-down” approach, using gross-level estimation techniques on feature sets, then employing progressive elaboration and rolling-wave planning methods to drill down to the task level on a just-in-time basis, iteratively uncovering more and more detail each level down.
Top-down vs. Bottom-up
The traditional method for estimating projects is to spend several weeks or months at the beginning of a project defining the detailed requirements for the product being built. Once all the known requirements have been elicited and documented, a Gantt chart can be produced showing all the tasks needed to complete the requirements, along with each task estimate. Resources can then be assigned to tasks, and actions such as loading and leveling help to determine the final delivery date and budget. This process is known as a bottom-up method, as all detail regarding the product must be defined before the project schedule and cost can be estimated.
In the software industry, the use of the bottom-up method has severe drawbacks due to today’s speed of change. Speed of change means that the speed of new development tools and the speed of access to new knowledge is so great that any delay in delivery leaves one open to competitive alternatives and in danger of delivering an obsolete product.
The top-down method addresses this key issue, by using the information currently available to provide gross-level estimates. Rolling-wave planning is then used to incorporate new information as it’s learned, further refining estimates and iteratively elaborating with more detail as the project progresses. This method of learning just enough to get started, with a plan to incorporate more knowledge as work outputs evolve, allows the project team to react quickly to adversity and changing market demand.
The Ideal Time is probably still the most commonly used technique for estimating any piece of work. It is simple, you look at the requirement and then think how long you think it will take to complete this piece of the work. The Ideal Time estimation is heavily used in waterfall projects.
The advantages of Idea Time estimation are:
- Simple to understand and use.
- In the beginning, the teams will be more comfortable using the Ideal time than story points.
- Stakeholder and other external people can easily understand the estimate.
- Each part of the team will give estimate independently without taking into account the impact on the other functions within the team. The developer will give the estimate without considering the impact on tester and tester will give the estimate without talk to the developers.
- Confusion between ideal time and real time. If the team has given the estimate of 5 ideals day, then management might hold the team accountable to completing the task within five days. Whereas their difference in ideal time and real time. The estimate of 5 days ideal time means that it would take the developers entire time doing nothing but working on this for five days. Whereas in reality, those five days effort will be done over many more days because ideal time does not take into consideration, all the distraction and meeting that team members have every day.
Tools for Sizing and Estimating
Now let’s examine the specific tools and techniques that agile teams use for adaptive planning. I’ll start by explaining how sizing and estimating fits into the planning process, and discuss the tools used for these efforts roughly in the order they are used, from the decomposing requirements to estimating the work items.
Sizing, Estimating, and Planning
Agile planning process is broken down into three steps: sizing, estimating, and planning. In agile the process of converting requirements into estimates and plans goes through a specific sequence:
- Size: How big is it?
- Estimate: How quickly can we get through it?
- Plan: When can we do it?
As discussed earlier in this post on agile projects the breakdown is called value-based analysis and decomposition, and it is done through iterative is planning. But let’s look at the typical structure of this composition.
The product features are first broken down into smaller chunks of work called user stories. Then, as the team further refines their plan, they break down the user stories into smaller chunks, called tasks. In other words, features are larger than user stories, which are larger than tasks.
However, some teams extend this basic model by adding epics, which are larger user stories that span one or more iterations. Keep in mind there is no single universally agreed upon way to do this. Some teams put the epics above the user story level. In this case, the epics might be above or below of the features – or “epic” might just be used in place of “feature.”
I have explained user stories and epics in more detail in a separate post [click here]. But in a nutshell, a user story is defined as a small chunk of business functionality within a feature that involves roughly 1 to 3 days worth of work. Agile teams typically break the product features down into user stories and write them on index cards to enter them into a requirements management tool (e.g. Jira). They also use a prioritized backlog of these stories to align the team’s priorities with the customer’s needs.
The 3 C’s
Each user story consists of 3 elements, which are known as the “3C’s” – the card, the conversation, and the confirmation.
- Card: The user story card includes just enough text to identify the story because the card is simply a token that represents the requirement for planning purposes. It doesn’t provide all-inclusive requirements – You can describe it as a “contract for a conversation” with the product owner. Asked planning proceeds, the team might add notes to the card about the story’s priority and cost. The card is often given to developers when the story is scheduled to be done and returned to the customer when the story is complete.
- Conversation: The details of the story arc communicated via a conversation – Hey verbal exchange of ideas, opinions, and information between the customer and the development team. This discussion takes place both when the story is being sized and estimated (during the release planning) and when the story is prepared for development (during aeration planning). This conversation might be supplemented with documents, which will ideally take the form of actionable examples.
- Confirmation: This refers to the customer’s confirmation that the story has been implemented correctly. Confirmation means that the product increments passes the customer’s acceptance test and meets the agreed-upon definition of “done.” These criteria are defined at the start of the iteration when the customer and the team develop the examples that will provide the basis for acceptance testing the outcome.
INVEST: Characteristics of Effective User Stories
There are several characteristicsGood stories, and fortunately, there is an easy way to remember them. INVEST stands for Independence, Negotiable, Valuable, Estimatable, Small, Testable.
- Independence: Although tough to achieve, the goal is to be able to reprioritize and develop user stories in any order. You must try to create independent user stories that can be selected on merit, rather than dragged into the release because other user stories are dependent on them.
- Negotiable: A story is not a contract. A story IS an invitation to a conversation. The story captures the essence of what is desired. The actual result needs to be the result of collaborative negotiation between the customer (or customer proxy like the Product Owner), developer and tester (at a minimum).
- Valuable: If a story does not have discernable value it should not be done. Period. Hopefully, user stories are being prioritized in the backlog according to business value, so this should be obvious.
- Estimatable: A story has to be able to be estimated or sized so it can be properly prioritized. A story with high value but extremely long development time may not be the highest priority item because of the length of time to develop it. What happens if a story can’t be estimated? You can split the story and perhaps gain more clarity. Sometimes splitting a story doesn’t help though. If this situation occurs it may be necessary to do some research about the story first.
- Small: As discussed stories are small chunks of work, but how small should they be? The answer depends on the team and the methodology being used. Too small of a story (2-hour story) is not also not good because it would be considered as an overhead for tracking.
- Testable: Every story needs to be testable in order to be “done.” In fact, I like to think of testable meaning acceptance criteria can be written immediately.
User Story Backlog (Product Backlog)
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.
- The backlog should not be confused with a “requirements document”.
- There isn’t a mandated format to represent the backlog: it can be an Excel document, a text file, a database or a collection of index cards or Post-It notes. This last, physical form is, however, the most common among Agile teams.
- A backlog in physical form mitigates the risk of creating multiple, conflicting versions, which would be a dire mistake given the backlog’s function as a “single trusted source” of the work to be done.
- Another key aspect of backlog items is their “atomic” aspect, as opposed to a narrative document in which, for instance, a single sentence could contain several distinct requirements, or conversely describe one requirement over several paragraphs of detail. The physical form also encourages this “atomicity”.
- The backlog should not describe every item at the same level of detail, or “granularity”. Features and tasks which are expected to be delivered in the near future should be broken down into fine-grained items and accompanied with details such as acceptance tests, UI sketches, etc.; whereas items planned for a more distant future can be described at a more macroscopic level.
Refining (Grooming) the Backlog
Backlog grooming or refinement is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity. Some of the activities that occur during this refinement of the backlog include:
- removing user stories that no longer appear relevant
- creating new user stories in response to newly discovered needs
- re-assessing the relative priority of stories
- assigning estimates to stories which have yet to receive one
- correcting estimates in light of newly discovered information
- splitting user stories which are high-priority but too coarse-grained to fit in an upcoming iteration
Exam Tip 1: Keep in mind that the customer is responsible for setting the priorities and making sure the backlog is up to date. The delivery team is responsible for estimating the work so that the customer can prioritize the work based on a cost-benefit assessment. The team does not do any of the prioritization.
Exam Tip 2: The tools and techniques listed in th exam content outline also include the term “requirment reviews.” If you encounter this term on the exam, be aware that it is essentially another name for the process of refining or grooming the backlog.
Relative Sizing and Story Points
People are not very accurate at making absolute estimates, they are better at making comparative estimates. Therefore, to estimate more effectively and accurately, agile teams rely on relative sizing. Story Points are the most common unit of measure for agile teams that practice relative sizing.
The most common scale used for story points is the Fibonacci sequence (1, 2, 3, 5, 8, 13, and so on). The benefit of Fibonacci is that each number is roughly 60% greater than the previous one (with the obvious exception of 1 and 2, of course). This streamlines the conversation by preventing debates about whether a story is a 6 or a 7, for instance. The difference between a 6 and a 7 would be small enough as to not be worth the time needed to come to a consensus on it. So long as the team can come to a consensus about whether a story is a 5 or an 8 (which is a more significant difference), the estimation process will result in the desired outcome.
Guidelines for Using Story Points
For the exam, you should be familiar with the following guidelines for using story points to estimate user stories:
- The team should own the definition of their story points. Your team will come up with estimates and allocate story points.
- Story point estimates should be all-inclusive. You should not need to add extra time to the project for testing and refactoring. Your story points should include all known activities required to complete the stories.
- The point size should be relative. e.g. A 2-point user story should involve about twice as much effort as a 1-point story.
- When disaggregating estimates, the totals don’t need to match. When adding up task points, it may not equal user story point. If the difference is a lot, you should be alarmed and investigate but typically as you decompose a story and learn more about what is required, your estimates become more accurate and may be different from originally estimated.
- Complexity, work effort, and risk should all be included in the estimates. The total time required to complete a story is a function of its complexity, its level of risk, and the amount of effort involved.
A great article to read on relative estimating can be found here: https://www.excella.com/insights/sizing-agile-stories-with-the-relative-sizing-grid
Affinity estimating is a technique many agile teams use to quickly and easily estimate a large number of user stories in story points and grouping items into similar categories or collections i.e. “affinities.”
There are 3 main parts to a successful affinity estimation session:
- Backlog grooming and prioritization
- Relative estimation (sizing)
- Story-point grouping
So how do you do it? Take a look at http://tracks.roojoom.com/r/86625#/trek?page=2 or the video below:
T-shirt sizing is a way to practice relative sizing. By comparing stories, you can break them into buckets of extra-small, small, medium, large, and extra-large. Each team will establish the size of a story relative to the others. For one team, a medium may be twice as big as a small; for another team, it may be three times as big. The important thing is that the relative sizes are consistent over time. Once this is established, we can use our estimations to achieve predictable releases.
A story map is a high-level planning tool that agile stakeholders can use to map out the project priorities early in the planning process, based on the information available at that point. A story map is essentially a prioritized matrix of the features and user stories for the product that is being built. Once created, it can be easily adapted to serve as a product roadmap that shows when features will be delivered and what will be included in each release. The team will then refer back to this roadmap as they progressively elaborate and refine their plans during release and narration planning.
To create a story map, we start by listing groups of features for the product horizontally across the top of the matrix, from left to right. Down the columns, we arrange the user story cards in each feature in descending order of priority.
Backbone: These are the stories that describe the essential functions needed for the system to work.
Walking Skeleton: These are the stories that describe the smallest version of the system that will meet the customer’s basic needs. These are features of the MVP.
A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. story maps, as shown above, are a common way to show product roadmaps.
The product roadmap has several ultimate goals:
- Describe the vision and strategy
- Provide a guiding document for executing the strategy
- Get internal stakeholders in alignment
- Facilitate discussion of options and scenario planning
- Help communicate to external stakeholders, including customers
Wideband Delphi is a group-based estimation technique in which a panel of experts submits estimates anonymously so that none of the participants know who has made which estimate. This anonymity produces improved estimates because it minimizes the cognitive and psychological biases that can result in flawed estimates, including:
- The bandwagon effect. People tend to converge around the viewpoint that is gaining the most adherents, even if it doesn’t reflect their own opinion.
- HIPPO decision making. Nobody wants to disagree with the boss.
- Groupthink. Making decisions to maintain group harmony rather than expressing their honest opinions.
Planning poker is designed to provide a faster, more efficient process that has all the advantages of Wideband Delphi. Here is how it works:
Each estimator is holding a deck of Planning Poker cards with values like 1, 2, 3, 5, 8, 13, 21. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.
The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.
Release and Iteration Planning
Agile projects are divided into release and iterations. As discussed earlier, an iteration is a short, timebox development period, typically 1 to 4 weeks in duration. A release is a group of iterations and that results in the completion of a valuable deliverable. An agile project will have one or more releases, each of which will contain one or more iterations, as illustrated in the above sections.
Types of Iterations
The activities done in the iterations are the heart of the agile development process. However, not all iterations are equal. Some play a special role in the project. The most common types of iterations are the development timeboxes during which the team builds increments of the product. However, on some projects, the team may need to schedule other types of iterartions as well. These iterations are planned and implemented just like development iterations but don’t focus on building a product increment. For example, the team may have “iteration 0” scheduled before starting development “iteration 1”. By definition “iteration 0 doesn’t build any deliverable for the customer. Another example may be that the team schedules an “iteration H”, “hardening sprint”, or “release sprint”, after all iterations for a release has been completed. The purpose of this iteration may be to stabilize the code, document the product, etc. Keep in mind that both these iterations are optional and may not be needed.
Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths. Or simply doing a proof-of-concept.
These are “spikes”. You can call them research spikes, or architectural spikes, or refactoring spikes if you wish.
A spike as an investment the Product Owner makes to figure out what needs to be built and how the team is going to build it — in advance of actually building it. The Product Owner allocates a little bit of the team’s capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.
Exam Tip 3: On the exam you may see 2 types of “Spikes.” Architectural Spikes, and Risk-Based Spikes. However, in the real world, the 2 are interchangeable and commonly called a Spike.
An architectural spike is a short, timeboxed effort dedicated to “proof-of-concept.” We are basically checking whether the approach the team hopes to use will work for the project.
A risk-based spike is a short, timeboxed effort that the team sets aside to investigate – and hopefully reduce or eliminate an issue or threat to the project. These short experiments to investigate risky portions of the project are a key tool for risk management.
If a proof-of-concept effort isn’t successful we can try a different approach. But if none of the approaches we try are successful, we reach a condition known as “fast failure.” Despite the name, fast failure can be a good thing as rather than continuing the project and eventually failing, you may pull the plug on the project and allocate the remaining funds and resources to another project that is awaiting resources. This concept is commonly used on R&D type projects.
High-Level Planning (Visioning)
Before you can start planning the first release, you need to complete the high-level visioning process. This involves identifying and roughly sizing the product features and user stories. Keep in mind that you are doing “just enough” estimating to map out the overall effort required for the project to get the work started. To do this, you are using the tools we have already discussed: affinity estimating, T-Shirt Sizing, story maps, etc.
You would typically want to include the product owner, sponsors, stakeholders, and perhaps some key members of the delivery team.
Outputs of High-Level Planning
There are a few things that need to come out of your high-level planning session:
- An updated, prioritized backlog of user stories and risk response actions.
- High-level (coarse-grained) relative estimates for each user story.
- A release goal focused on customer value.
- A target date for the release.
Planning and estimating in the agile world depend on a single key metric: the development team’s velocity, which describes how much work the team can get done per iteration. Given a team’s known velocity for its last project (if it is known), a release plan represents how much scope that team intends to deliver by a given deadline.
Release deadlines are often fixed, imposed externally by such things as tradeshows, accounting pressures, or contractual obligations. But since the goal is to get working software into the users’ hands as quickly as possible in order to make “course corrections” as soon as possible, every effort is made to keep release software development cycles as short as possible. Agile release cycles should certainly be kept shorter than a year, and are often as short as 6 months or 3 months. A release is, in turn, made up of iterations. As discussed, iteration length will typically be fixed at a length somewhere between a week and a month. If the release is in 6 months and iterations are going to be 2 weeks each, the release will consist of 13 iterations.
During a release planning meeting, we will:
- Assess the prioritized backlog and review the sizing of stories, resizing them as needed.
- Sort the stories by release, selecting those that will be in the upcoming release, the next release, and future releases.
- Refine our original outline or roadmap for the upcoming release, changing it as needed.
- Slice the stories that will be done in the upcoming release into pieces of work that are small enough to be completed within one iteration.
At the end of the release planning session we should have:
- A shared understanding of the release goal
- A list of the stories to be done in the upcoming release, sliced into manageable chunks
- A roadmap for completing those stories
- A rough outline of what will be done in the future releases
Note that releases are planned around delivering useful and valuable functionality to the customer. A release may be date driven (demo or trade show coming up) or functionality driven (once we can capture customer orders we can go live).
Velocity is a measure of the amount of work a team can tackle during a single Sprint or iteration. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
Points from partially-completed or incomplete stories should not be counted in calculating velocity. Velocity should be tracked throughout the Sprint on the Sprint Burndown Chart and be made visible to all team members.
Velocity is a key feedback mechanism for the team. It helps them measure whether process changes they make are improving their productivity or hurting it. While a team’s velocity will oscillate from Sprint to Sprint, over time, a well-functioning team’s velocity should steadily trend upward by roughly 10% each Sprint.
It also facilitates very accurate forecasting of how many stories a team can do in a Sprint. For forecasting purposes, the average of the last three Sprint’s Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders.
Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.
Slicing the Stories
User stories come in different shapes and sizes. Large stories, also called epics, allow quickly sketching product functionality, which is handy for scoping a major release. But it means that larger stories have to be eventually refined and broken down into smaller, detailed ones, which the development team can implement.
To explain this better, I found a great example on https://www.romanpichler.com/blog/refining-user-stories/
Grooming the product backlog entails breaking down user stories from larger product backlog items until they are small enough to fit into a sprint. Although detailing product backlog items should be delayed until the last responsible moment, you might have to start refining a story a couple of sprints in advance before it can be implemented, particularly if the story is large or complex. Let’s look at an example of how user stories can be broken down progressively.
As the picture above illustrates, the epic “Compose email” is broken down into several stories. The user story “State recipient” is then further decomposed into two more fine-grained stories. These are now small enough to fit in a sprint.
The epic is an example of a compound story, a user story that has more than one goal. To decompose such a story, we introduce a separate story for each goal. “Compose email” is therefore broken into “State subject,” “State recipient,” and “Set importance” to allow an incremental delivery of the functionality. This technique is also called slicing the cake.
There are other user stories that need to be made smaller, including complex stories and stories with monster criteria. A complex user story is a story that is too big to be delivered in one sprint because of its inherent uncertainty or because it covers too much functionality. If it is too uncertain, you may want to introduce one or more items into the product backlog that explore that uncertainty and generate the relevant knowledge, for instance, “Investigate JavaServer Faces as the user interface technology.”
Stories sometimes look fine until we consider the acceptance criteria. If there are too many—more than about five—or if requirements hide in the criteria, you should rework and decompose the story. Here is an example: “As a user, I want to delete a text message.” The acceptance criteria state, “I can select any text message. I can remove the message text. I can save the modified message.” Not only is the second condition redundant, but the other two introduce new requirements rather than specifying acceptance criteria. This story should be split into three: a story about deleting text messages, a story about editing text messages, and another story about saving the modified messages.
The Iteration or Sprint Planning meeting is for team members to plan and agree on the stories or backlog items they are confident they can complete during the sprint and identify the detailed tasks and tests for delivery and acceptance.
Iteration lengths typically range between 1 and 4 weeks. The team holds a planning meeting at the beginning of each iteration to break down each of the features scheduled for the iteration into specific technical tasks. Iteration or agile sprint planning meetings generally last from 2-4 hours – any more than that and you may be spending too much time in unnecessary planning; less time than that and you may not be doing enough planning and collaborating.
Iteration Planning Process
Here is a closer look at how it all goes down:
- Discuss the user stories in the backlog
- Select the user stories for the iteration
- Define acceptance criteria and write the acceptance tests for the stories
- Break down the user stories into tasks
- Estimate tasks
Once the work is underway during an iteration, team members hold a daily meeting, timeboxed to 15 minutes. During the meeting each team member, in turn, briefly answers the following 3 questions:
- What have you worked on since the last meeting?
- What do you plan on finishing today?
- Are there any issues or impediments to your progress?
Ground Rules for Daily Stand-Ups
- If you have a task, you must attend
- Only those who have tasks talk
- Speak to the team, not the coach or ScrumMaster
- No side convos
- Create a new sticky note for each new task started
- Discuss issues after the meeting
- Solve problems off-line
Exam Tip 4: Remember the ground rules of stand-up meeting and that the meeting is for the team by the team!