Relative mass estimating

25 Jun 2015
by cvringer

Why relative mass estimating?

Scrum teams are often asked to quickly estimate new stories without knowing much details. How do you roughly estimate those “high level” stories fast, in let’s say, one hour?

Enter “Relative Mass Estimating”, also known as T-Shirt size estimation.

These roughly defined stories (or epics, or what you want to call them) can, for example come from a roadmap defined by the business. A high level description is provided, such as ‘Customer can view his invoices’, or ‘Customer can change his contract’, but no details are available yet. So the team should quickly decide were the data could come from, and which systems could be involved. Usually teams are very good at this, especially when they are long lived (feature) teams.

Relative mass estimating is done by the Product Owner, Scrum Master en the entire devteam.

The following rules apply:

  • We divide only in Large, Medium, Small. No stories in between;
  • As always: Estimates are estimates;
  • We estimate with the knowledge we have at this time;
  • We do not ask for detailed information;

The Scrummaster creates 3 area’s, which are called ‘Large’, ‘Medium’ and ‘Small’. I use just 3 labelled A4 papers, and put them on the floor.

Now the estimating begins. The Product owner explains the story shortly, and hands the story over to the team. The team has a short time to common understand what is asked. (If needed, a timer can be set). Then the team decides where to put the story. (L, M or S). The first story will probably the most difficult, but after that it will go faster. If the team cannot decide, you can use thumb-voting to force a decision. Sometimes the team can decide to re-arrange stories, because they got better insights or a story was estimated with wrong assumptions. There must be time for that. We did this workshop for one hour, and we relatively estimated more then 60 stories.

So what is the value of relative estimating, and what can we do with the results?

Our end goal is to estimate the number of sprints the story would take to build. This allows us to look further into the future and very roughly tells us when items from our backlog can be build. (We could use this in a burn-up for example). It also provides the Product Owner earlier insights about the realization of the roadmap, so he can shift priorities. After the relative mass workshop, the team can estimate one or two stories of which it is pretty clear what to build in ‘number of sprints’. Other stories in the same category will be assigned the same number of sprints. Another possibility is to T-shirt size each L, M and S again, to get more refined story estimates, and then pick one ore two stories to estimate in sprints.

One comment:

  • Richard Wijdenes on June 25, 2015 at 12:35 Reply

    Not only is this a quick estimation method, its also fun! And overall understanding off the user stories within the team will improve.

Leave a Comment:

* - required fields

© Keienberg Consultants