The Product Owner’s Dilemma

“The new product must be delivered by November 30th at all cost” – who in product development has not already heard such demands by their stakeholders? Or: “You’ll have to work overtime when the deadline is coming closer!” is also popular. “Can IT estimate whether they can deliver Scope X until the end of the next quarter?” Nice is also: “We need a project plan so that we can manage the risks of the project better.”

How can Product Owners and development teams positively deal with such pressure? How can the following goals and questions effectively be addressed?:

• Are we still “on track” or do we already have to communicate a deferred delivery of thenext release?
• How can we convey that the additional feature X will put the planned delivery date atserious risk?
• How can we quickly develop a good feeling about the feasibility without defining andestimating the full scope in advance?

Developing products for customers is a highly complex endeavor. There are imponderables everywhere. Which features will be of the highest value for customers?Which requirements have to be implemented in which way? How long will the development of certain features take? These are questions that simply cannot be answered reliably in advance. There are many unknowns in the game, especially when you begin the journey with a team that has just been put together.

It is therefore all the more coherent that such projects are often approached iteratively,using empirical management. This lies at the very core of agile product development. Itmeans that the work that must be done is not defined and planned at the beginning butrather that it develops over time. The idea is to work in small steps against a goal and tocontinuously incorporate newly gained knowledge along the way into the developmentprocess. This also enables reacting to unplanned events at virtually any time. However,this causes a problem for stakeholders, sponsors, and those in charge of the productdevelopment: it becomes difficult to predict delivery dates of product features,milestones, or even the entire product.

In the development of our e-commerce platform, we use so-called Burn-up Charts to continuously reflect upon our progress and to enable forecasting for our sponsors. We explain how we do this in the remainder of this text.

What is a Burn-up Chart?

If you have ever concerned yourself with agile methodologies such as Scrum, you might know burn-down charts. Teams use burn-down charts on a daily basis to record the amount of work they have been able to complete from the given scope in an iteration.

As shown in Figure 1, in a burn-down chart is visualized how progress is made incompleting work from a given scope (red line). Ideally, the rate of completing work isnear an ideal, linear line (grey line) that runs straight from the top left to the lower right.This can help the team to learn whether they are on track managing their work and howlikely it is that they will deliver the planned scope.

This works well for tracking during an iteration because these are usually short and their scope is fixed. A typical iteration in Scrum – called a sprint – has a duration of one to four weeks. But what about forecasting for a whole product or a product release of which we neither know the exact scope nor the rate at which a team can deliver results of their work?

This is where burn-up charts come in handy: in principle, a burn-up chart is an upside-down burn-down chart in which the completed work is recorded. The resulting curve runs from bottom to top. The gradient of the curve reflects the rate at which work is being completed – the velocity. We use burn-up charts at the iteration-level, that is at the end of each iteration in the project, we record how much work has been completed. The actual trick, however, is to use a second curve that shows the complete known scope at the end of each sprint. Typically, the complete scope will be small at the beginning of a project and grow over time.

This is illustrated in Figure 2: the red curve, showing the work completed, runs towardsthe blue curve which shows the complete known scope at that point in time. 

This way, we visualize well how completed work compares to the complete scope that is planned. Moreover, this enables us to forecast. A product release is done when the red curve intersects the blue curve. 

Forecasting in agile Product Development

We plot trend lines at the earliest possible moment so that we can forecast when the curves might intersect. With every iteration we update all curves and trends, increasing their accuracy. The following assumptions are the basis for the trend lines: the velocity of the team(s) will increase slightly after the first few sprints and then stabilize at a certain rate. On average the red curve will therefore be a nearly straight line and it is fair to assume a linear trend for that curve if the team(s) remain stable. 

Figure 3: Burn-up Chart with Forecast Trends

For the blue curve, we use a logarithmic trend. This is based on the experience that thescope usually develops rapidly in the beginning before it becomes rather asymptotic.We often see that, in product development, little is known about the exact scope in thebeginning. The amount of work that is believed to be necessary then usually growsquickly and stabilizes when more and more knowledge about required features is addedto the product backlog. That is, the full scope of the product becomes clearer withtime. 

In our example in Figure 3, the full scope of the release is expected to be delivered in sprint 6. Room for maneuver results from either adjusting scope or from taking measures for increasing team velocity. However, as we know, the latter has smaller potential (“The Mythical Man-Month”, Frederick P. Brooks), and is in the short term nearly impossible.

Why not Storypoints?

Alert readers may have picked up that the vertical axis in the burn-down chart (Figure 1)is captioned with “Story Points” while in the burn-down chart (Figures 2 – 4), we use the“Number of Issues”. Using story points is omnipresent in Scrum. Story points are an abstract measure, putting features and requirements (often User Stories) of different sizes into relation to one another. This relative estimation helps teams to better plan the amount of work they want to take into one sprint. Each team develops their individual scale of story points, which means that a story point has no meaning outside the team.

We do not use story points in our burn-up charts, instead, we work with the number of issues because:

• Story points would be possibly more accurate but allow for what is known as Gaming(Goodhart’s law: “When a measure becomes a target, it ceases to be a good measure”);
• With story points we would require an always completely estimated backlog so that wecan draw the blue curve;
• The imprecision is unproblematic to make a forecast. Greater precision does not addany new information.

That user stories differ in size does also not have a negative effect because what concerns us is the question: “Is there still work to do or not?”. The average size of the stories remains largely the same and is therefore not of any consequence. 

Release Management

By continuously visualizing the known full scope compared to the current work that has been completed, we uncover the main options to tweak in product management. This helps all involved to understand what is possible and under which conditions a release may be delivered at a specific date. Managing scope is by far the most effective activity if there is the need to deliver in sight of an approaching deadline. 

Step by Step

In our development, we use several milestones. These are stage goals on our roadmap, each of them reflecting a certain subset of features of the product’s full feature set. They may be seen as early product versions. The scope of a milestone usually reaches a stable condition faster than the product’s full scope, allowing us to get a good impression early of when specific goals can be reached.

Advantages

Clear Stakeholder Communication

l essential information is conveyed at a glance, including (sometimes) inconvenient truths. Arbitrarily, illusionary chosen deadlines will be quickly exposed as unrealistic.What’s possible will become apparent.

Gaming – Fudging improbable

Whether intentional or unintentional, teams will hardly be able to influence this kind of progress tracking in any way. So-called gaming becomes very unlikely. This is because additional stories would later have to be closed at some point. In other words: if additional stories would be used to pretend greater progress, they would be counted in the full scope as well. The distance between both curves would be the same.

Chopping stories into smaller (and thereby more) chunks would have the same effect.This would be compensated by the fact that then more stories would be completed per iteration.

Continuous Improvement built-in

Indeed, the forecast will be rather rough and imprecise at the beginning. However, after only a few iterations you will get a good understanding of what will and what will not be possible.

This helps to better get to know the teams and learn about the specifics of the entire ecosystem in which they operate, allowing conclusions concerning possible structural issues. The forecast will become more precise and more reliable with time.

Focus on Essentials

The visualization focuses on the essential parameters, namely velocity, and scope. This clears the view and puts the action-guiding information right in your hands. 

Summary

Using trend lines in combination with specific assumptions, which can be sketched in as data points, we can simulate and assess different scenarios. Every team will have to develop their individual strategies and solutions. For example, we have found it very useful in our project to assume a scope of approximately 600 stories towards the end of the project to visualize the converging scope, as shown in Figure 4. This enables us to keep track of a delivery date that we are approaching in about one year.

This puts product owners in a better position when “negotiating” with stakeholders and sponsors, as the effects of feature creep on the delivery date can be highlighted well and clearly. For example, I sometimes make it clear as a product owner in such conversations that only 20 are “allowed”. This helps to manage expectations without an elaborate estimation process.

Finally, this approach allows us to even work with progress reporting in percentages in an agile project. The asymptotic curve reflecting the assumed scope tells us the expected amount of work without having defined all user stories or work packages in advance. This lets us elegantly derive the overall progress of the increment.

Our approach has immediately convinced our sponsors and executives when we first showed it to them. Another acknowledgment of the usefulness of this practice.

This article has also appeared in German:

• Burn-up! Forecasting in der agilen Produktentwicklung

About the Authors

Dr. Timo Volkmer operates this website. He began his career as a consultant in computer science and information technology. He is an expert in agile product development, organization design, and works as a coach in these fields. Momentarily active at DER Touristik Online, he has previously worked as a freelance consultant for various corporations throughout Germany in agile transformations. Timo is dedicated to working with teams who create products that customers love.

Jörg Malang has worked as a product manager since 2008, having held several positions as a chief product officer in enterprises of different sizes. Since 2018 he is a freelance consultant and owner of the “Senior Product Leadership Group (SPLSG)”. He advises enterprises in building effective and efficient product development processes. Jörg is dedicated to developing product strategies and loves agile, customer-centric product development. At the moment Jörg works on a freelance-basis for DER TouristikOnline as product owner.