Sometimes your Product Owner or the business wants to know how much work there is on the Product Backlog. They want to get an idea for the Roadmap ahead. Or perhaps to acquire some (internal) funds. Or as a Scrum Team, you want to know what is coming. So there could be several reasons why you want to get an estimation of unestimated Product Backlog Items (PBI). For this, there is a method called ‘magic estimation’. In this blog post, I will describe a method and my experience with it as a Scrum Master. I have done it with my Scrum Team for several Product Backlogs. We were already developing the products, so we had a baseline and feeling with the products and our estimations.
First things first
Preparing this session properly makes the time the whole team sits together more efficient. A boundary condition is to have the titles of the Product Backlog Items clearly formulated. There must be as little room for interpretation as possible. Print for every PBI the title on paper. Then cut this so you have a small strip for every PBI. Make sure your team has a baseline. Otherwise, determine one in the session together.
- Lay down one set of Fibonacci numbers of the planning poker cards in order on a table including the question mark. Leave enough space between the cards.
- Give every team member a set of about the same amount of strips of unique PBIs.
- Explain the process and rules to the team. It is not allowed to talk or practice non-verbal communication unless told so.
- If the product is not known to the team, let the Product Owner share her/his vision of the product.
- Let every team member, in turn, put every PBI of her/his stock at the number at which (s)he estimates it. You can let the team member read the title of the PBI first aloud. In my experience, this costs extra time, but the upside is that every team member has heard of every item on the Product Backlog. This way the team gets more feeling with what is out there. Everybody else is not allowed to give any kind of reaction. Write the number on the strip of paper.
- If someone does not know what is meant by a PBI, it can be placed at the question mark. This is treated later in the next step.
- Also write the question mark on the strip of the PBI. Perhaps the Product Owner wants to reformulate the title afterward to make it more clear.
- The PBIs placed at the question mark are now explained by the Product Owner. If the intention is clear, they can be divided amongst the group to be placed at a number. You can do this immediately or in the second round (see below).
- Now starts the second round. This is done in total silence and without non-verbal communication. Every team member can simultaneously pick up a PBI and replace it. He can confirm the magic estimation by placing it at the same number or give it a different magic estimation by placing it at a different number. He also writes down the (new) number after the previous magic estimation. This way it is clear which PBIs have already passed round two. This is done until all PBIs have an extra number. Everybody can do it at her/his own speed, so some will replace more PBIs than others. But the session can continue faster this way.
- Now do another round. You can do more rounds if you want, but for us, three works well to get enough magic estimations per PBI to make a conclusion and for the session not to be too long.
- Roundup and draw conclusions in two steps:
- For PBIs that have changed slightly, for example, within a range of three following Fibonacci numbers, calculate the mean and write that down as the final magic estimation. This range can be [1,2,3] or [3,5,8]. If you think the distance between 3 and 8 is too big, you can also make ranges of a maximum of 3 story points, e.g. [2-5].
- PBIs that have changed more than in the previous step need to be discussed centrally. Let every team member who has written a number on it explain the reason behind it in one sentence. Then try to discuss a common magic estimation. Keep this discussion compact, because it is not a regular refinement. If it is not possible to reach an agreement take the mean of the magic estimations that remain standing.
All PBIs have a magic estimation. Everybody has an idea of the amount of work on the Product Backlog. But what is still unknown is the hidden work that surfaces when the team actually develops the PBIs. Keep that in mind, because it is a rougher estimation than the regular estimation.
My sources of inspiration
Has your Daily Scrum become a bit boring? Is everybody just sending, but not listening? Has the interaction been lost? Then it’s time to spice up your stand-up! It wasn’t this awful in my team, but during one of our Sprint Retrospective we discussed our Daily Scrums. The interaction was a little bit lost. One of the Agile principles is: Individuals and interactions over processes and tools. The pitfall of the Daily is that it can feel like a mandatory part of the process instead of an opportunity to exchange information and help each other. A part of that mandatory feeling is answering the three questions: What did I do since the last Daily? What am I going to do until the next Daily? Do I encounter any impediments? In a previous team it even felt like reporting that you actually worked. Off course we kept the Daily and the three questions. But we changed the format to make it more dynamic. Every team member used to answer the questions for him or her in turn. Now we put more focus on the Sprint progress and the progress of completing Story’s and deploying releases. We did this by addressing each lane on the Scrum Board separately. On each lane there is either a Story, the current release, or non-blocking bugs on the bugs lane and some independent tasks on the support lane. We created the bugs and support lanes to keep things transparent, even if team members were working outside the Story’s we’ve got in a Sprint. Also the deployments of the release to Acceptance and Production needs some work of the team. Therefore we created a separate lane for it as well. By addressing each lane separately we keep focus on progress on the completion of the work of every lane. Now every team member answers the three questions in regard to the lane. For example: What did I do since the last Daily for this Story? What am I going to do until the next Daily for this Story? Do I encounter any impediments while working on this Story? The answers also include: When do I expect to be done with a particular work item? Such that another team member can review it. Or it can be tested. Or somebody else can use it for another work item. This works especially well if back-end and front-end work is done by specialized developers. This improved interaction between team members (individuals) to tune their work to each other. At our next Sprint Retrospective we evaluated this change. Everybody was really positive about the extra interaction it brought. Besides that the focus on completion led to a more steady burn-down. We kept it ever since.
The Scrum Retrospective is the closing ritual of a Sprint. This is the moment for the team to reflect on the past Sprint. For good collaboration and productivity of the team it is important to take time to improve these things. By letting the team come up with their own action points of improvement, you’re ensured that they’ll find them important and will implement them. There are many ways to implement the Retrospective. In this blog I’ll describe a way I developed and tested in practice with my team. I’ll describe the method in detail and present alternatives on some points. Important to the Scrum Retrospective is to provide space for all team members to express themselves and to express the things they are occupied with. To this end, a safe environment must be created, but also literally the space and time for anyone to have their say. First, I’ll outline some important preconditions. By setting these, you’ll have a good foundation. This makes the execution go more smoothly. Only a good conversation leader is still necessary to guide everything. The program for this Retrospective consists of a relatively short individual part and the rest is collective. The solo part is done in silence first. This way everyone can first think for themselves how the Sprint has progressed and what he (and she) considers important for the Retro. The common part is to understand each other’s views and experiences and then jointly come to action points that everyone can commit to. Suppose you’ll have 1 hour, that is 60 minutes, for the Retro, then the program can be laid out as follows. If you have another timebox, you can of course change the program accordingly. There are in total five rounds. Somebody can monitor the timebox of the rounds with a timer.
Set the stage: grading In order to get everyone in an active and open attitude, each team member gives a rating for the last sprint. This is also called
team happiness. This can be useful to compare different Sprints and to monitor progress in the experience. In addition to a number, another scale may be used, such as five stars or bad, moderate, sufficient, good, excellent. If a grade feels too much like reporting, then you can also ask for a single word to describe the Sprint. The latter also promotes creativity.
Gather data: argumenting Next, everyone writes his reasons for his grade on post-its. These are observations and can be both positive and negative. It is useful to use different colors of post-its for positive and negative observations. Take
10 minutes for this. Only if everyone is done earlier you could stop earlier. It’s important to do this individually and in silence. This way, the team members don’t influence each other. During this round everyone has the maximum freedom to express themselves on post-its. Next, everyone orders his post-its in order of importance. The most important one is on top. Both positive and negative are stacked together.
Generate insights: discussing themes In this round everyone stands up for an active attitude. They all stand around a blackboard, flip over or a glass wall. At least it has to be surface on which post-its can be stuck. Everyone can start a new theme in turn. It goes like this. The first team member hangs up his most important post-it. He explains this at the same time. Anyone may ask questions to clarify the arguments, observations, experience, problem, cause or issue. After that, everyone can stick a post-it that belongs to the same theme, next to it and read it and, if necessary, clarify it. This will continue until everyone has hung his post-its on this first theme. Then another team member may hang his most important (from the remaining post-its) as the second theme. The rest of the process goes the same as with the first theme. Then another one can start a third theme. This will continue until everyone’s post-its are finished or the timebox has expired. A timebox of
20 minute is appropriate. You may choose to let everybody stick and read their remaining post-its after the expiration of the timebox. However, they are not discussed further in detail. Sometimes it can be difficult to determine whether a new post-it belongs to the same theme or that it is actually a new theme. Usually this becomes apparent after there are hanging multiple post-its related to a theme. Then you can decide to split the theme. Let this happen dynamically and don’t be too rigid about it. Grouping by topic are only required to determine the topics to be discussed in the next round. At the end of this round, all post-its with observations are grouped by theme. Based on the number of notes per subject, it is clear how important it is. As a team, you’ll choose the most important or most important two to take to the next round. This also depends on whether two subjects have about the same number of notes or that a subject jumps out. You could also choose to determine the priority of the subjects by giving each team member a number of votes and holding a ballot. I ain’t in favor of this, because this way the team members can influence each other. My statement is simple, if someone has not written a note about a subject, he doesn’t deem that topic important enough. With a voting round, everyone can influence or convince each other to choose a topic.
Decide what to do: form action points In this final round we’ll become concrete. We are going to formulate action points. These must be formulated
SMART. These are agreements with the team that team members can hold each other to. Take 30 minutes for this round. For this round we will sit again at the meeting table. We will discuss the most important 1 to 3 themes to formulate up to 3 action points for them. Three is indeed a proven number to work on in the next sprint (and afterwards!). Too much will lead to loss of focus. It’s important to formulate these action points concrete and SMART, and especially discuss the boundaries of the agreements to make them clear to everyone.
Close the Retrospective: wrapping up Thank everyone for their contribution and ask for a quick review of this format. With this last feedback, the Retro itself can be improved. Hopefully, you will find this blog post useful and will put this whole format or partly into practice. I would like to hear your experiences.