In our first blog post Agile Product Planning – Insight into a Project | 1/2, you already saw how we defined goals and built the backlog for agile product development. Now we’re picking up right where we left off and showing you how we created a forecast from those backlog items using simple methods. To do this, we use relative estimation of backlog items and the team’s velocity. This forecast helps us understand what will likely be completed by a certain point in time – and it’s also a great tool for communicating with stakeholders.
Everything is Relative – Estimating with Magic Estimation
To estimate the size of different backlog items, we use the Magic Estimation method. It’s a relative estimation technique that lets you quickly size up multiple backlog items. Why? Because it’s done almost entirely in silence, which helps avoid getting stuck in endless debates. Experienced teams can move super fast with this method and get more accurate over time by relying on past experience. For example, we once estimated 100 items in just 2 hours!
Preparation
First, we gather all backlog items that are already written as user stories and place them on the left side of a brown paper or online whiteboard. On the right, we lay out the Fibonacci scale in a row and prepare reference items for each value – these are completed epics or stories that clearly represent each point on the scale. This makes it easier for everyone to compare and estimate the size of new items. We also define what we mean by “epic” – in our project, it’s any story that doesn’t fit into a single sprint. For us, that meant anything over 21 Fibonacci points or story points, with each sprint lasting 14 days.
Of course, in addition to the Fibonacci scale, two categories must not be missing: one category with a “?” and one with a “teapot or coffee pot.” If someone places an item on the teapot during estimation, it’s time for a break. Items under the question mark, on the other hand, are so unclear that they cannot be estimated. In our experience, this happens when stories are not written clearly enough. Once all necessary preparations are complete, the board looks like this:
Estimation
Once the board is prepared and the Scrum team has been invited, the estimation can begin. To ensure as many perspectives as possible, we recommend conducting the estimation with an interdisciplinary team. Team members can include, for example, Product Owners, Scrum Masters and developers with different specializations. It is also helpful to involve a moderator who is familiar with the estimation process.
The estimation of backlog items proceeds as follows:
- The participants, without speaking, take the epics from the left side of the board, assess the effort required for each epic and place it under a reference item that seems appropriate to them.
- After that, participants either take another epic or move one that another participant has already estimated. Each time an epic is moved, it receives a mark in the form of a point.
- Steps 1 and 2 are repeated until all items have been estimated.
- Only the epics that have received 3 or more points are discussed by the team and then jointly re-estimated.
Once all the epics have been estimated by the team, the result will look something like this:
Using Velocity for a Realistic Forecast
The final forecast is kind of like a weather report – it’s based on past data, in our case the team’s velocity. If the team is new, it’s best to go through 3–4 sprints first to get stable velocity numbers for the forecast. This may take some time before a team can work together well. In our case, the team had already done several sprints together, so the estimation went smoothly and everyone was on the same page.
Our stakeholders wanted to know what output to expect after 7 sprints (14 weeks). We calculated the average velocity from the last 7 sprints: 131 story points. One variant could not be ruled out so we looked at the minimum and maximum from the past. Minimum velocity: 80% of the average → 2 epics drop out. Maximum velocity: 120% of the average → 2 extra epics. This gives us a “cone of uncertainty” – just like in weather forecasts – that we can share with stakeholders. You can also visualize this using a burndown or burnup chart, but we usually go with a process-based view since stakeholders relate to it better.
Because Magic Estimation is so quick, we can easily update the plan as new insights come in and repeat steps in the planning. Of course, requirements engineering doesn’t stop here. We continue refining the epics, breaking them down into user stories, adding acceptance criteria and enriching them with models and UI prototypes. Check out our webinar recording: “How Agile Requirements Engineering can Support Your Product Planning”. We walk you through how to build and live a shared product vision with your team.
Looking for professional support with your agile product development project? Reach out to us – no strings attached – and find out how our Scrum teams can help you move forward.
Discover MID’s Agile Services now!
