Burn-up! Forecasting in Agile Product Development

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.

Product management – the three disciplines

Based on my personal experience I would see three disciplines
for any senior level product professional

  • (Product) Strategy: Is based on the company’s business strategy and gives a long-term guidance on which products & services will build a competitive advantage. Which features will create value for customers and business? The product strategy is based on the company’s current and/or future capabilities.
  • (Agile) Ways of Working: Enables a learning organization based on agile principles and best practice. Makes sure organization builds a sustainable competitive advantage based on its “people platform”.
  • Product Development: Ensures delivery of agreed products & services in scope, on time & on budget

All three disciplines must be addressed together. Also, a good role definition should include aspects of all three. In an ideal world, the surrounding organization would be a mature product company. I have posted about this earlier here.

Beyond Design Thinking

Today on Twitter, I stumbled upon the following article: “Beyond Design Thinking” by @kevinmccull.

Interesting to read that the concept of “Design Thinking” might be starting to become out of date. But then I realized that it is increasingly being absorbed within a much more strategic approach “for designers”.

Main learning: don´t believe in buzz words, but find your own way to use frameworks.

My motto is: “Digital Strategy Implementation & Design Thinking”. How about yours?

Bridging the gap between the CxO Suite & Product Development

A challenging role for Chief Digital Officers

Three steps towards successful digital transformation

To successfully respond to the (digital) challenges, there are three simple steps: Have a clear picture on where to go, understand the current situation of your business and ensure the transformation.

The challenge

Having a clear picture of the future is all about understanding what products will be successful looking forward. Already now it is clear that those products will be based on user interactions (“big data”, “social”, “sensored” context, etc.) and therefore will have to be very close to the behavior and needs of customers. The ways how companies will deliver services to their customers will be increasingly digitally driven. Even the pretty much innovative CVS Extra Care only gives an indication on what will be possible in the future. (So far) other companies like LinkedIn or XING are purely digital. XING have started with the vision to manage your professional network digitally and have become very successful with this. Starting from real life groups, its services have evolved into virtual ones. At the same time, XING isn’t limited to online networking only. It is all about a seamless integration of both worlds – with focus on building superior solutions and services for customers.

How to address the challenge

In other words, there is a strong need for a concrete product vision and strategy. If a CDO is not a strong Product Manager, he/she won´t be able to come up with it. And yet this won´t be enough. This strategy needs to be embedded into an overarching corporate strategy – and the entire CxO suite is responsible for that. The CDO needs to apply state of the art Design Thinking tools. The CEO might be that strong Product Manager, in this case a CDO might not be necessary. But how many CEOs of larger companies are good at defining a product vision and a product strategy? And even if they are, a CDO might be a good facilitator of the CxO suite discussions on behalf of the CEO. There is a successful role model for that already: supply chain management. A Supply Chain Manager doesn´t necessarily make the final decisions but is having the whole value chain in mind and facilitates the process. This person makes sure, all decisions are aligned to the supply chain strategy. The CDO needs to do the same: ensuring all decisions are in line with the product strategy of the company.

Understanding the current situation seems to be obvious, but isn’t trivial. The biggest challenge will be to “make the boat leave the harbor” and not to think too incrementally. A CDO will have to be the tireless warner to be more bold while acknowledging reality (e.g. business modeling, the skills available, the time it will take etc.).

Last, the transformation needs to happen in reasonable steps to get to the clear product vision of the CDO. The biggest risk that the steps are mixed up with the final vision. Even the CVS Extra Card is just a first step towards a vision. What will come next? There should be ONE answer, and then it can be broken down into the responsibility areas of the functional experts.

Benefit for companies

The CDO must pave the path into the (digital) future. As Product Manager she/he needs to come up with answers. Building the right products will be decisive for the (digital) future of companies.

Why understanding the needs of your users cannot be outsourced

In this week´s session about Information Systems and outsourcing @HEC we have discussed what to think about when considering outsourcing. One quote was “don´t outsource the problem, but outsource the solution”. This is interesting from a Product Manager´s point of view.

One thing I keep talking about, is that one should refrain from jumping to solutions too quickly. Before that step, a Product Manager needs to understand the problem to be solved for the users. And this requires going deep on the needs of users and thinking about their mental model. So, if you are thinking all day long about potential solutions you might start on the wrong foot. Actually, you might even consider not to outsource your product development at all nor to trust your own product development teams to come up with the right solutions.

I am sure that some readers of this post will even doubt the necessity to understand the needs of the users. This is a core competence and not peripheral. Outsourcing the solution is legitimate, but outsourcing your problem (aka understanding the needs of your users) is not an option.

If you see your own product development team as a vendor, what are you doing to direct them? What is the “contract” between you and them? Do they know enough about the problem to be solved so that they can operate on their own? Considering your own product development teams as “external vendors” might help you refrain from micro managing the solutions they come up with. You need to focus on your core competency: understanding the “problem space”.

 

 

What do product management and soccer have in common?

Have you ever observed a bunch of fans watch a soccer match in a pub? They all seem to know best what strategy to follow, what to do next etc. Now go into a product related meeting with managers at a company and look what is going on there. Listen to the comments people are making, the thoughts they are having and to what extend they are listening to the experts in the room.

I often do experience this. Product management is a little bit like marketing creatives: everyone has an opinion. Even the consumer out there has an opinion. Actually, some executives suggest to run product management by surveys. The majority of asked users decide about the next feature. The rest is project management only. It is as easy as that.soccerproduct Is it as easy as that? For sure not. I do see at least three dimensions where this thinking is falling short:

  1. Users don´t know what might be the best solution for what they need (you know the story about the faster horses, do you?)
  2. Listening to users today only partly gives the needed answers for tomorrow´s products. (There is anticipation of technology developments needed. Think of the tablet phenomenon or the touch screen.)
  3. Users only see their part of the delivery system (aka the user interface). Actually they don´t have to understand the complexity of delivering the service to them. And they shouldn´t. But this doesn´t prevent us from having to go beyond the obvious.Think of a service like a flight. It is much more than the airplane and the stewardess serving us. There is a whole machinery behind delivering the service to customers. (“Nonstop you” is a nice Lufthansa slogan that describes this pretty well.)

So, Product Managers need to make their points in discussions. Going beyond the obvious means elevating the discussions to a different level. Refuse to discuss only visuals for example. A couple of times I experienced situations where people didn´t listen to the results of my qualitative user interviews. They didn´t want to know about the personas created. The mental model was too abstract for them, etc. They only woke up when I started sharing screens. Then suddenly everybody had something to contribute. But they were not able to reference their input back to the framework introduced before. So it became generic without adding any value.

Soccer coaches are typically hired for at least an entire season. And I am sure they don´t always listen to the fans. What counts is coaching a winning team. Let your Product Managers build winning products. Input welcome, but decisions stay with your product coaches.