Our team was asked to give a rough estimate of the expected costs for a new project. We had never previously worked for the client nor had we started yet with any stories, so we had no numbers for comparison. However, all currently known User Stories were written in collaboration with the client.
To give us an estimation in a reasonable amount of time, we used a technique called “Magic Estimation”, even though I really dislike the name. Magic?! Luckily, there is absolutely no magic behind the technique. Instead, the method is based on the idea that experienced teams demonstrate a very good “gut feeling” about stories, even when a lot of variables remain unknown.
To start with, the Product Owner prepared a highly visible project map, including post-it notes with comments. He then printed the User Stories including links to the concept. The stories were divided amongst the team, with each team member taking around 10 stories to evaluate.
In a designated area, we prepared notes with the numbers 1,2,3,5,8,13, 20 and “?”. As it was not possible to estimate the stories relatively to another, we decided to use “2” as the effort of one work day.
Every team member read his stories, cross-checked with the concept if necessary and asked the Product Owner for further information where needed. It was however strictly forbidden for them to discuss the stories amongst each other.
After around 40 minutes, all the stories had been assigned to numbers. Most stories were assigned between 2 and 5, no story was estimated higher than 8 points Two stories were marked as “?”.
Next, every team member had to take one number, read all of the stories assigned to this number and check the relative size against the other stories assigned to this number thus confirming the estimate. If the team member agreed with the estimate, he set the story aside and marked it as “estimated”.
However, if he disagreed with the original estimate, he moved the story to another that he thought best fitted the story. While doing so, the story was marked with a sticker and the original number was added.
All the stories that we moved in this secondary process had to be evaluated by a third member. If the third member of the team agreed to the new number, we set it aside and again marked it as “estimated”. If the third reader disagreed again, we took the story out of the flow to discuss later.
Out of roughly the 50 stories we began with, only 5 couldn’t be agreed on. Two more were marked as “?”, one of those was withdrawn by the Product Owner to request more detailed information. The other story marked ‘?’ had to be explained in detail by the Product Owner, after which we had a further group discussion and we were able to clarify the work that needed to be done and agree upon an estimate.
Finally, we came to tackle the five stories that had been disagreed on more than three times during the estimation process. As a team, we were able to identify the possible problems and uncertainties with the stories, and eventually were able to estimate all of them.
The whole session lasted for 90 minutes and was very valuable for the Product Owner and as an experience for the team. The fact that no story was estimated over ‘8’ showed that the PO had done a great job in preparing them.
Overall, I found the method worked well, we were successful in estimating a large number of stories in a reasonable amount of time. I think however that our success was based on the fact that we had a well prepared PO, a team who is used to working together and who had worked with planning poker before..
I will use it again in the future as long as I can find a better name for it. 🙂
The way we used the technique was based on these three posts:
I had the pleasure of joining Steve Hoyler (@zurcherart) at a demonstration of LEGO® Serious Play®. Steve gave a four-hour demonstration of the method he is using to help management visualize their idea of a perfect company and what it takes to get there.
For me, the most interesting part was how Steve ran the workshop.
Generally, the setup is a group of people who don’t know each other, but will have to create an idea together using LEGO. Not only will they have to collaborate, but they will have to use LEGO, something most of us probably haven’t used or thought of for a very long time.
To break the ice, everyone had to talk to another member of the group for one minute, followed by introducing this person to the rest of the group. As a concrete task, Steve asked us not only to introduce the person, but also to at least name the persons favourite film. Felt like a pattern applied, but it worked well.
Immediately after, everyone was given a set of LEGO parts and the task to build the highest tower at the table in 10 minutes. This way people got comfortable with the tool they were about to use, in this case LEGO bricks. As an interesting side effect, the way the different participants approached this, gave some hints about their character, or at least how they wanted to be perceived by the group (the pattern of learning more about someones character, by giving out a task and observe how the task is approached and not the solution).
For instance, one guy in our group immediately started building with the clear goal to get the tower as high as possible. He was using all kinds of tricks to attach the different parts to another and was on the fast track of building the tallest tower at the table.
Someone else put together two pieces of LEGO, announcing that he’s a very bad architect and that he’s done. He then proceeded giving away his leftover pieces to the first guy, thus completely ignoring the task but rather supporting someone else who was obviously more enthusiastic about it. Most of the others just tried more or less successfully to build a tower.
Shortly after, Steve announced that the tower has to be “earthquake resistant”. In doing so he set the rules for the workshop: “Requirements for tasks will, and can, change often during the process”. By the end of the timeboxed task, we all had to place the towers in the middle of the table for the earthquake test. Some of the group immediately used leftover pieces to reinforce the towers by connecting them with another. This was not in the task. It was however also not explicitly forbidden and most of the towers survived the earthquake test.
The fact that some team members immediately bent the rules to support each other and didn’t thrive for personal profiling was probably a clear hint that we didn’t come from a corporate background.
Now that we were past the initial introduction plus and had tried our hand at some actual LEGO building, it was time for some self-reflection. The task was to pick the part from the tower that mostly resembles the work we’re doing for our daily jobs. The concept sounds rather strange and abstract but surprisingly most of us immediately were able to locate a part and talk about it. Interesting.
Time to move on and so we did. In the next scenario we were told we will be the owner of a very successful company in the future. The assignment was to represent this company with LEGO bricks, making sure to emphasize why the company is so successful. The approaches were wildly different, some of the participants reflected in an abstract way the network of the different departments of their company and how they work together. Others represented a specific key workflow. Either way, everyone came up with a result, which was rather surprising, considering we only had some minutes to come up with an idea of a successful company and at the same time represent it in LEGO blocks.
After introducing this personal vision to the group, we each had to pick a single key element of our design and then work together as a group to create a new vision, including all the chosen key elements from our own individual creations. Now this was tricky. Not only did we have to find common ground amongst the visions, it was also inevitable to break down the models we had only just created. The idea behind this task is clear: To overcome personal pride, exchange yourself with others, listen to their reasoning and find a way to co-operate together. After all, all the key elements had to be included in the group model.
The lesson then went further, moving to more theoretical parts of describing the new model and then writing down what good things we already do at the place we’re currently working plus what we unfortunately don’t do at the moment. Steve went on explaining how the workshop could go on further, but for us it ended here with a final group discussion.
The workshop was very interesting to me for various reasons. Not only did I get to observe Steve’s technique of how to run a workshop, but also learned some new concepts of how a seemingly abstract element (a piece of LEGO) can represent an idea or even our daily jobs. On top of it, as a participant, I myself was able to experience some patterns applied, always interesting.
More information: http://www.amiando.com/engage-using-serious-play.html?page=1105720