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 the next release?
- How can we convey that the additional feature X will put the planned delivery date at serious risk?
- How can we quickly develop a good feeling about the feasibility without defining and estimating 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. It means that the work that must be done is not defined and planned at the beginning but rather that it develops over time. The idea is to work in small steps against a goal and to continuously incorporate newly gained knowledge along the way into the development process. 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 product development: 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.
Figure 1: A typical sprint burn-down chart in Scrum
As shown in Figure 1, in a burn-down chart is visualized how progress is made in completing work from a given scope (red line). Ideally, the rate of completing work is near 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 how likely 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.
Figure 2: Burn-up chart for a product release
This is illustrated in Figure 2: the red curve, showing the work completed, runs towards the 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.
Trend Lines for Forecasting
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 including trend lines for forecasting
For the blue curve, we use a logarithmic trend. This is based on the experience that the scope 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 the beginning. The amount of work that is believed to be necessary then usually grows quickly and stabilizes when more and more knowledge about required features is added to the product backlog. That is, the full scope of the product becomes clearer with time.
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.
What about 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 we can draw the blue curve;
- The imprecision is unproblematic to make a forecast. Greater precision does not add any 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
All 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.
Built-in Continuous Improvement
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 the 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.
Figure 4: Burn-up chart with trend and assumption of future scope
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.
Dieser Artikel ist auch auf Deutsch erschienen.
About the authors
Dr. Timo Volkmer 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 Touristik Online as product owner.
