A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past, but how does a new team that perhaps even has people who are new to agile get started with story points? As I mentioned in another blog post, Ideal Days is a story point estimation scale that blends size with effort and degrades the backlog sizing process into a drawn-out time estimation exercise. Given that a points scale like the Fibonacci sequence that relates more to size/complexity is preferred, how does a team get started when it does not have a baseline story against which to do relative sizing?

A few things should be in place to set the stage for establishing a baseline story:

1. Definition of Done. This should include quality assurance and user testing.
2. Sprint length. Should be no longer than two weeks.
3. Understanding by the team that high throughput is achieved via low work in process, i.e. having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint.

Once there is a set of stories in the backlog that are small enough to pull into a sprint, the next step is to discuss and assign story points. In asking the team to assign story points for the first time, I usually tell them something like this:

Team, we know that in order to meet our sprint goals we need to get the first story in this sprint coded, unit tested, and into QA by the second or third day of the sprint. Let’s call that a three point story.

With that in mind, the team sizes the first few stories. Some might argue that we are just using Ideal Days. We are not, because executing and supporting the QA and user testing efforts are not included in the goal of getting the story to QA by the second or third day of the sprint. The other reason we are not using Ideal Days is because we only use this method for sizing the first couple of stories in the backlog. After that, all estimations are done relative to those first couple of stories that were sized, by asking whether or not a story feels bigger or smaller than those stories.

Reflections:

•  Establish the Defintion of Done, sprint length, and concept of high throughput via low work in process before sizing stories.
•  Size stories with the goal of getting the first story into QA within the first few days of the sprint.