- Get to work quickly, deferring on elaborating all of the details up front.
- Accommodate changes quickly and easily, maximizing value while keeping the cost of change low.
As larger items bubble their way up to the top of the list because other items are completed or discarded based on new information, they too will be split into smaller work items as part a regular refinement process. The implication here is that the PBIs are prioritized according to value. (The latest Scrum Guide now refers this as an ordered list that I won’t delve into here. See my post Order in the Backlog! for additional discussion.)
As an agile team elaborates a PBI, it is the opportunity to – with no wasted effort or extra cost – increase value in the eyes of the customer by incorporating feedback from previous deliveries. This is how the Product Backlog is emergent, supporting a principle of the Agile Manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.” Agile teams have the authority – and are expected – to shape the solution collaboratively, leveraging insights and information obtained from feedback.
The Product Backlog thus needs to be dynamic as opposed to a static to-do list. Re-prioritizing items, adding new items, modifying existing items, and deleting items occurs on a regular basis, based on feedback. And let’s not forget that with short cycles, agile teams have the regular opportunity experiment with how to deliver that value more effectively, in support of another principle of the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Since there is a certain lack of up-front precision and the likelihood of some ambiguity with what is being delivered and how it will be accomplished, this begs the question: How do we know when an agile team will deliver?
If you are new to agile planning – or preferably forecasting since planning occurs throughout an agile development effort – remember the primary expectation: The benefits of agile are achieved by working differently. Agile teams forecast delivery dates based on their working knowledge of the Product Backlog Items (PBIs) and the time and effort required to implement – fully implement – them in a quality manner.
While agile planning differs from traditional planning because elaborating the detailed requirements and tasks are deferred, the end result of initial forecasting doesn’t differ much from traditional planning in that an agile team – especially a new team with no established cadence – is “guesstimating” how much work it can complete with quality, honoring the global definition of done and the individual acceptance criteria for the PBIs. This initial guesswork, however, is quickly replaced by the evidence of actual delivery once an agile team gets to work, providing a very accurate indicator of progress.
Agile forecasting is different from traditional planning because we have a Product Backlog that consists of a mix of items that are more fully defined than others. Referring back to the different sized PBIs of Figure 3-8, an important distinction is that a PBI with greater scope will require more effort to implement than a smaller PBI. It is the difference in effort that we want to understand as one of two key variables related to agile forecasting.
Agile forecasting is a two-step process that completes the DEEP acronym by addressing the estimated – or sized – quality of a Product Backlog. The first step in forecasting involves relative sizing. Relative sizing embraces that we can readily tell the difference in size between a two-story house and a multi-story office building, or that the distance to our neighborhood grocery store is much shorter than another point clear across town. The leverage point is that we are faster and better at perceiving differences between sizes of things than we are at estimating time, and that is the advantage that we want to exploit.
When it comes to software features, once teams get a little practice they can quickly and easily determine if one feature will require two or three times more effort to implement relative to another, smaller feature. The next component to complete the relative sizing step involves a couple of paths.
There is the “classic” agile approach that keeps the time component completely separate from the effort required to implement a PBI. Story points were introduced as a means of disciplining organizations away from one problem outlined in the Common Scenario from Chapter One: confusing a time estimate with a firm commitment. The goal of story points is to allow a team to put together a realistic, quality-oriented, effort-based delivery plan and then derive how much time is required to meet that plan once the effort is understood.
Using story points (so named because User Stories have become a de-facto standard for capturing agile requirements), each PBI is assigned a numeric value that represents the effort required to implement that PBI relative to another PBI. Changing a text label on a web page may be a story point of “1”, for example, while adding a filtered search engine to an application may be considered a “13” because it requires significantly more effort to implement.
The Fibonacci sequence is typically used to assign story points (0, 1, 2, 3, 5, 8, 13…) because when used to represent sizes, the Fibonacci numbers increase at about the same rate that humans are able to easily perceive differences. (Johnson, 2011) There was, however, a modification to the sequence made by Mike Cohn that is worth pointing out.
The next number after 13 in the Fibonacci sequence should be 21. Mike changed this to 20 (and modified other higher numbers, so the modified sequence is 13, 20, 40, and 100) because when some people saw a value of “21” they associated it to being a very precise estimate, an impression that a larger number in this context is certainly not intended to convey because we are dealing with something that is much larger and broader in scope. (Cohn, 2014)
After sizing the Product Backlog with story points, the team is ready for the next step. While I’ve worked with teams that have had no difficulty with the concept of story points, this has not been universal. Using values that don’t have a time component associated with them goes against some deep-rooted beliefs that we must estimate work in hours or days and add up all of the information to arrive at a delivery date. I have seen people really struggle with the concept of having no time associated with PBIs during the relative sizing step.
An alternative (with thanks to Dion Stewart of DevJam) is to continue to leverage the speed of relative sizing while establishing what it will take time-wise to fully complete each PBI, remembering that done means done. We’re retaining relative sizing because we don’t want to slip back into exclusively using time-based estimation, as this always ends up being more cumbersome and does not improve accuracy in return for the extra time and effort expended.
Begin by grouping similarly-sized PBIs together, and use a relative grouping without associating numbers with each PBI. The goal is to quickly sort and group the work based on the perceived differences in size.
The next step is to assign an “ideal days” to each group, where a “1” is one day to fully deliver (design, code, test, document…) a PBI as a team, and so on. Ideal days create that a link to time estimation that people are comfortable with versus the more abstract story point values. Each PBI will thus have a certain number of expected ideal days associated with it. The term ideal days means that an ideal work day is not a full 8 hour day, since we need to account for overhead and interruptions.
Whether you use story points or ideal days, remember this advice: If you want speed, stay out of the weeds! It can be tempting to dive into the details of a work item or to be overly precise about an estimate. This will bog you down and add little value in the long run. Keep any discussion to a high level – the capabilities that each story needs to deliver – and keep the focus on how much effort one PBI entails relative to other PBIs.
In either case, an agile team will have a Product Backlog with numbered values. This brings us to our second variable related to agile forecasting: velocity.
The team then needs to project its velocity – or how much work it can accomplish as a team in a short (1-4 weeks) delivery cycle. Just as knowing our average speed will tell us how long it should take to drive across country because we know how many miles are involved, the pace at which a team works through the Product Backlog allows us to gauge where the team will be at a given point in time.
If the team has sized the Product Backlog using story points, it should pick a small PBI and determine how much time they feel it will take to implement it by tasking out the work. If the team is using ideal days, this will naturally capture the amount of time the team needs to deliver any given PBI. (A good cross-check is to task out the work here as well.) In either case, the team can then project – based on the team size and the length of its delivery cycle – the number of PBIs that can be completed in each cycle.
Let’s say that the Product Backlog contains 300 points, representing the cumulative total of all the desired features for a targeted release. The team will be delivering using two week cycles. They begin by projecting their anticipated velocity, and then continually measure their actual velocity for each two-week cycle.
They establish a 25-point per two week cycle cadence, which means that they will require 24 weeks to work through the 300-point backlog. A “line in the sand” can be drawn showing when delivery is forecasted to be, as shown in Figure 3-9:
This may be perceived as bad news that the initial estimate was off, but the good news is that have early proof about what the team can actually deliver. It gives us the ability to seek out options early on in the process: Can people be added without making the team too large? Can we split the work out across two teams? Can the date be re-negotiated? Is it possible to reduce the scope of some PBIs or remove lower-priority items altogether? Can the team do anything – or can management assist the team in any way – to maximize their velocity?
What I like about agile development is that you get a reliable, early indicator of progress – or the lack thereof. You don’t have to wait unit you reach that 80 percent “complete” on a project plan only to discover that you have 80 percent more work to do.
You may be wondering how agile teams meet delivery dates by accommodating change, welcoming “…changing requirements, even late in development” as one of the agile principles begins.
Given that agile development embraces change, we will be faced with change, but this does not necessarily need to translate into increased scope. When faced with change, we need to have a conversation and address some key questions about where the change fits into the overall Product Backlog picture and priorities:
- Is the change a “must have” for the current release? If so, is this change more important – more valuable to the customer – than other Product Backlog Items that are queued up for the team?
- If the change must be implemented, can other work be moved off the list if we need to meet a specific date, or can the date move?
- Can the change be added into the bottom of the list as a “might have” and not a “must have”?
- Are there other options – based on what the team has learned – to reduce the scope of other items that will meet the needs of the customer so that this change doesn’t impact the forecast?
Another benefit with continuous feedback and change is that an agile team begins to learn more about the customer truly values as the product is being built. This allows information and insights gleaned from past, short deliveries to be applied to future PBIs as they are refined. This reduces the potential for change because the team is more in tune with the customer, helping the overall effort stay closer to the schedule.
And remember, because we are using a just-in-time elaboration of details we eliminate waste that comes from detailing requirements in advance and then either changing or discarding them altogether. The goal is to keep the cost of change low.
Agile Forecasting is Fast and Reliable
My own experience with agile forecasting is that it is both fast and very reliable. It is counter-intuitive at first because it doesn’t seem logical that we can achieve speed and accuracy through what appears to be imprecision, but we’ve proven with traditional planning that extra time and effort doesn’t lead to greater accuracy and predictability.
The bottom line is that we can forecast delivery without details, and we can provide ourselves various opportunities along the way to maximize value by actively managing the variability that we encounter.
This post is a draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran
Cohn, M. (2014, Jan). FAQs. Retrieved from Mountain Goat Software: http://store.mountaingoatsoftware.com/pages/faqs
Johnson, C. S. (2011). The Elements of Scrum. Foster City, CA: DYMAXICON.
Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Boston, MA: Addison-Wesley.