Tag Archives: Estimating

Relative Estimating with T-Shirt Sizes

Posted on by

A variation on estimating using story points is to use what I call “T-shirt sizes”.  This table shows the sizes I like to use.  The abbreviation is a good way to refer to the size in a tracking system.  The weighting factor helps you make more precise trade-offs between stories that need to fit into a development cycle.

Name Abbreviation Weighting Factor
Freebe freebe 0
Extra-Extra Small xx-small 1
Extra Small x-small 2
Small small 4
Medium medium 8
Large large 16
Extra Large x-large 32
Extra-Extra Large xx-large 64
Too Big too big –

I really like to use this method to estimate stories because they:

  1. Expresses the relative estimate idea well
  2. Are easy to explain to stake-holders

This method expresses the relativity concept well because, unlike story points, it has meaning in the “real world”.  When you use shirt sizes it easy to understand the idea of relativity and you don’t automatically compare the estimates to anything like dollars, days, or weeks.  Even though the estimate isn’t precise, it has real meaning that is easy to understand.

I found that when attempting to associate with software product stakeholders, it can be difficult to explain our unusual ways.  In some environments, this means that stakeholders won’t show up to meetings or have trouble being willing participants in discussions such as software product stories and estimates.  If developers don’t get enough communication with stakeholders and customers, it can seriously harm product value.  Using concepts that are less intrusive can be a big help.

The “Freebe” is just as it sounds.  It is a feature that won’t count as a part of your budget.  This is not because it has no size; it just means that it is so small that talking about it takes more time than doing it.  Many freebes will add up to an xx-small eventually.

“Too Big”, just means that the team cannot accurately estimate the story because it doesn’t appear to fit into a development cycle.  This is especially easy to understand when the team works in sprints or iterations.  The easy way to take care of these is to simply divide them into smaller stories.

The weighting factor is really the same thing as story points.  The nice thing about these is you can make your own project-oriented weighting factors quite easily.   The thing is that you really need to keep them the same.  Make sure that you use a exponential equation to calculate them.  I suggest starting with ones like I have here, however.  I have actually used these numbers with great success.  You could use Fibonacci numbers too.  These numbers help you to have a better handle on how many stories can fit in a given time period.  You may only be able to do a single extra large story.  If they break down that story you could actually fit in 64 extra-extra small stories and possibly get more done with a little more planning effort.

Once you have these you have what you need to make your estimates for your stories.

Telling Good Stories

Posted on by

Estimating the time it will take to make a software feature can be quite a challenge.  In order to have a reasonable discussion about how long a feature will take, we really need to have a reasonable idea about what the feature is.  Good estimates depend on good software descriptions.

My favorite way to describe software, for the purpose of estimating, is to develop “user stories.”  User stories are short phrases that describe a behavior that the software needs to have.  I have used two different ways of writing stories that seem to work well for me, so I’m pretty sure there are more than I describe here.

I first learned about defining a software product using stories from the book “Extreme Programming Explained: Embrace Change” by Kent Beck.  Later, more definition was added by Mike Cohn who wrote a whole book on user stories.  Cohn has a handy formula for writing them.

He suggests that you follow this form:

As a [user] I can [some behavior]

For example you could write:

“As an ATM customer I can request my current account balance.”

Another one might be:

“As an ATM customer I can enter my PIN before I am given access to my account.”

This form is very popular and I find that it works great.  Before I learned about the Cohn story form, I had developed a form myself.  I still like it because I think I am able to break stories into smaller pieces more naturally and it has a cool side effect.

Simply finish this statement:

“I will know that progress has been made when …”

What you write after this statement is usually a great user story.  The Cohn form fits this method as well.  I also found a similarity with the results of my form and the development of a “User Manual”.  The sum of all of the stories could reasonably become the product user manual.  Check out these three stories:

  • I will know that progress has been made when the software provides a place for the ATM user to enter their PIN.
  • I will know that progress has been made when there is a way for a user to ask for their account balance.
  • I know that that progress has been made when the software provides a way for an ATM user to print their account balance.

Now listen to them without the “I will know…”part:

  • The software provides a place for an ATM user to enter their PIN.
  • There is a way for a user to ask for their account balance.
  • The software provides a way for an ATM user to print their account balance.

Notice that this sounds a lot like a user manual.  Steve McConnell in his book: “Software Project Survival Guide” describes a way in which user manuals can be used as requirements documentation.  I really believe that he was on to something when he wrote that.

The best stories are isolated, meaning they don’t depend on any other story.  This may seem to be too difficult at first, but it is actually quite possible.  Don’t give up on making great stories. Using practices like this can help to make it easier.