{"id":13722,"date":"2023-08-10T09:23:33","date_gmt":"2023-08-10T07:23:33","guid":{"rendered":"https:\/\/mid.de\/?p=13722"},"modified":"2026-01-28T13:47:00","modified_gmt":"2026-01-28T12:47:00","slug":"agile-product-planning-from-backlog-to-forecast","status":"publish","type":"post","link":"https:\/\/mid.de\/en\/blog\/agility\/agile-product-planning-from-backlog-to-forecast\/","title":{"rendered":"Agile Product Planning \u2013 from Backlog to Forecast | 2\/2"},"content":{"rendered":"

[vc_row][vc_column][vc_column_text css=””]In our first blog post Agile Product Planning \u2013 Insight into a Project | 1\/2<\/a>, 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 \u2013 and it’s also a great tool for communicating with stakeholders.<\/p>\n

<\/p>\n

Everything is Relative \u2013 Estimating with Magic Estimation<\/strong><\/h2>\n

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!<\/p>\n

Preparation<\/strong><\/h2>\n

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 \u2013 these are completed epics or stories that clearly represent each point on the scale.\u00a0 This makes it easier for everyone to compare and estimate the size of new items. We also define what we mean by “epic” \u2013 \u00a0in 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.<\/p>\n

Of course, in addition to the Fibonacci scale, two categories must not be missing: one category with a \u201c?\u201d and one with a \u201cteapot or coffee pot.\u201d If someone places an item on the teapot during estimation, it\u2019s 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:[\/vc_column_text][vc_single_image image=”14324″ img_size=”full” add_caption=”yes” onclick=”link_image” css=”.vc_custom_1768883796347{margin-bottom: 0px !important;}”][vc_column_text css=””]<\/p>\n

Estimation<\/strong><\/h2>\n

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.<\/p>\n

The estimation of backlog items proceeds as follows:<\/p>\n