This post is part of a series: Becoming Agile.
Usually we have certain constrains on our project which define what we can achieve and most likely also what we have to do first. Having a backlog packed with user stories makes it very difficult to get an overview of the upcoming workload. To be able to actually get an idea for the upcoming sprints we need to estimate the product backlog. Doing that detailed for each user story would take us quite some time. So instead of estimating each single user story (as exact as possible) we could try to estimate a bunch of similar user stories at once. This is Magic Estimation.
Let's assume we have a backlog packed with 80 user stories. Each of them has a decent description and also has acceptance criteria defined.
As a first step we need to set up complexity buckets. In those buckets we'll put stories with similar complexity. For simplicity we choose shirt sizes: XS, S, M, L and XL. The XS bucket is for stories which can be easily achieved in a couple of hours, whereas the XL bucket is for stories which we don't really have a clue on how to solve. All other stories would be evenly distributed among the other buckets.
The buckets get put on a board in form of cards. The user stories will be put next to the bucket cards.
The product owner starts by briefly presenting each user story. The team then has just a couple of seconds to decide on the complexity of the story. When time is up (the ScrumMaster could help here by watching the time) the story goes into its complexity bucket. This process shouldn't really take much longer than 30 seconds, certainly not longer than a minute. If the team cannot make a reasonable decision, just put the story in one of the higher ranked buckets -- we are not in a sprint planning, we just want to get an idea of the workload. Don't think about it too long, just shoot right away.
After all stories are distributed the team gets time to have a look over all buckets (in the meantime the product owner can go to get a coffee refill). Are there some stories which doesn't quite fit to the others? The team can take maybe ten minutes to reorder all stories. If there are stories which could make up there own bucket, create a new one. There might be real no-brainers which could all go into an XXS bucket. But don't try to create too many buckets, this wouldn't be much helpful.
Now all user stories are clustered into their complexity. In the next step we can put story points on the buckets: is the S bucket three or five points; the XL bucket might be 20 points. When all buckets have story points assigned, we can add it all up.
The sum of story points gives us a rough direction of how many sprints it would take to finish all user stories. At the end the product owner can use the estimated story points to prioritize user stories for the upcoming sprints. Furthermore, he can compare the estimation outcome with the product's time table if it is actually possible to do or maybe if some feature need to be cut down.
This approach is just one possible way of doing a magic estimation. There are other ways the team could do this:
(AL) = affiliate link
The links marked with (AL) are so-called "affiliate links". If you buy something from the seller via this link, I get a commission from your purchase. For you the price remains unchanged.
Die mit (AL) gekennzeichneten Verweise sind sog. "Affiliate Links" (Provisions-Links). Wenn du über diesen Link bei dem Anbieter etwas kaufst, bekomme ich von deinem Einkauf eine Provision. Für dich bleibt der Preis unverändert.