Forecasting without Details

January 13, 2014

A good Product Backlog is an enabler, allowing agile teams to:
  • 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.
In order to accomplish this, the Product Backlog should have four qualities that make it DEEP (Pichler, 2010):


Figure 3-8

Agile teams pull work from the top of the Product Backlog, where items are more finely defined than they are towards the bottom. This is what is meant by being detailed appropriately. Each Product Backlog Item, or PBI, in Figure 3-8 is represented by different sized blocks. The larger physical sizes of PBIs further down in the list in Figure 3-8 visually represent the greater scope relative to the smaller, more narrowly-defined PBIs at the top of the backlog.

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?

Forecasting 101
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:


Figure 3-9:

Notice that I said that the team established a 25-point per two week cycle cadence. Before the first cycle, the team may project that it can complete 35 story points per two week cycle. But once they get to work, it becomes an established fact that the team can only complete 25 story points every two weeks. It’s like calculating a cross-country trip, there’s bound to be unknown problems along the way that will negatively impact your anticipated velocity.

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.

Managing Change
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?
The goal is to manage this type of variability – customer feedback that impacts the overall value of what is being delivered – and refine the definition of the target Minimal Viable Product (MVP), which should also be a Minimal Valuable Product in the eyes of your customer(s). This is progressive planning in action, where we continually adapt along with making the impact of our decisions transparent and visible.

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

Bibliography
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.

23 comments

Michael said...

Thanks for the article. Very detailed and interesting.

June 5, 2014 at 10:05 PM
Vimax Asli said...

An interesting read for any person who would agree with your views.I curious more interest in some of them hope you will give more information on this topics in your next articles Obat vimax

June 30, 2015 at 5:05 PM
John Smith said...

Thanks you for this post… great information.
http://isl-schedule.in/indian-super-league-isl-opening-ceremony/
Watch ISL Opening Ceremony Online Live Stream HD Video
Indian Super League 2015 opening ceremony watch online

September 30, 2015 at 8:22 AM
Su lli said...

Articles provides useful information, Thanks for sharing!
Giải thích CMNR là gì và bắt nguồn từ đầu, chia sẻ các bạn cách làm mồi câu cá rô phi cực hiệu quả, tổng hợp các loài rắn độc nhất trên thế giới cực thú vị, khi bà bầu bị táo bón nên tham khảo bà bầu bị táo bón có nên rặn không, răng bị ê buốt thì phải làm sao tại cách chữa răng ê buốt cực hiệu quả, bạn lo lắng vì bị thâm quầng mắt thì tham khảo cách trị thâm quầng mắt hiệu quả nhất cực đơn giản, có lúc bạn nằm mơ thấy tình cũ thì tham khảo giải mã giấc mơ thấy người yêu cũ mang đến niềm báo gì, chia sẻ bí quyết cách làm món cà chua nhồi thịt ghẹ cực ngon, hay hướng dẫn cách làm cánh gà tẩm bột chiên xù cực thơm ngon, tìm hiểu về Tết Trung Thu thì tham khảo nguồn gốc của ngày Tết Trung Thu vô cùng thú vị.

October 2, 2015 at 11:27 AM
Lopez Alexander said...

Thanks for the best blog.it was very useful for me.keep sharing such ideas in the future as well. Thanks for giving me the useful information. I think I need it!
Plants vs Zombies , Solitaire,Tom And Jerry Games, Brain Games, Happy Wheels , FNAF World , FNAF

April 11, 2016 at 11:34 PM
agario games said...

Let’s keep out sites for your child! click:
brain games | puzzle games | tetris | happy wheels | agario | abcya | fnaf 4 | super mario games
To play for free!

April 25, 2016 at 2:14 AM
Anonymous said...

His subject is good, long while I find this topic and I think it is here, many thanks guys .

www.gmail.com sign up
Whatsapp status quotes images sayings messages
Happy Holi Wishes Quotes

May 27, 2016 at 6:01 AM
Candy Sim said...

All the best blogs that is very useful for keeping me share the ideas
of the future as well this is really what I was looking for, and I am
very happy to come here. Thank you very much
earn to die
earn to die 2
earn to die 3
Hi! I’ve been reading your blog for a while now and finally got the
earn to die 4
courage to go ahead and give youu a shout out from
earn to die 6
Austin Texas! Just wanted to tell
earn to die 5
Hi! I’ve been reading your blog for a while now and finally got the
happy wheels
strike force heroes
slitherio
you keep up the fantastic work!my weblog
age of war
earn to die 5

June 2, 2016 at 11:32 PM
vertix.io said...

I really hope to see the same high-grade blog posts from you in the future aswell.
vertix.io
Dog Games
Fighting Games
Subway Surfers
Mickey Mouse Games

June 10, 2016 at 12:47 AM
Lisa M. Henry said...

Hotmail is an email account of Microsoft Corporation. Like Google's Gmail, it is full of features usually xuyen.Neu of an email you want to register an account please follow these basic steps:
Hotmail login

Hotmail review

Sign in to hotmail

Login to hotmail

Recover hotmail password

Tank Trouble is a very interesting flash game about tanks, about war and about destruction
TANK TROUBLE | TANK TROUBLE 2

One Penguin Takes it personally when he is surfing the web and stumbles upon a web site telling him that he cant fly, after that he sets his mind to research and practice flying until he can prove the world that he can..
IO GAMES | Slitherio | LEARN TO FLY | LEARN TO FLY 2

Strike Force Heroes is a new game action-packed shooter from the creators of Raze; with 3 game modes, 15 campaign missions and over 65 weapons.
Strike Force Heroes 4

Strike Force Heroes

July 6, 2016 at 12:06 AM

Post a Comment