Silver Stripe Blog

This post is the first in a series of two posts. In this post, I’ll explain what story point estimation is about. In the next post, we’ll see why Agile teams prefer story point estimation over the traditional method of estimating in hours.

What are story points?

In simple terms, a story point is a measure of complexity. This is to differentiate it with hourly estimates, which are a measure of effort.

The second idea is that story points are a relative measure. That means we choose one user story and keep it as the reference and assign it a value of 1 point. We then measure every other story relative to this one. So if the second story is twice as complex, we give it a value of 2 points. Thrice as complex and it gets 3 points and so on. Go through the entire backlog this way.

Thats all there is to it!

The difference between complexity and effort
Lets take an example to highlight the difference between complexity and effort.

Assume I have a rock that weighs 10 Kg. This weight is a property of the rock itself. Now if I ask how long will it take to carry the rock over 100 meters. This depends on many factors: The weight of the rock, who is going to carry the rock, how strong they are, how fast they are and so on. The answer to the second question depends both on the rock, and the person doing the carrying.

In a similar way, complexity is a property of the story, whereas effort depends both on the story as well as the person implementing it.

Jon Kern:

For me, I chose to be pragmatic, NOT dogmatic. I chose to use my brain to do what makes the most sense in every circumstance, not a blind allegiance to a process for process’ sake. If barging forward and doing “design and coding” works best for you and your team to flesh out ideas, go for it. Just be sure to go back in and “do the right things” once you commit to an approach that is going to stay in the code base.

We released a new feature last week – the ability to define the type of each feature.

Continue reading ‘Defining feature types in Silver Catalyst’ »

Sometimes its pretty hard to prioritise. You can move features up and down the backlog, but you never really get a clear idea about the impact thats going to have. What does it mean if I put a feature at position 10 instead of 8? Will it make a difference?

Usually not. Except for one case – When position 8 would fit the feature into capacity for the next iteration, but position 10 just misses out on the next iteration. In this case, it could be very important indeed!

As Mike Cohn says, more interesting than what is in the next iteration is the knowledge of what is likely to fall just outside.

It is with this idea that Alistair Cockburn’s Iceberg List has been implemented in Silver Catalyst.

That’s a rather fancy name for a pretty simple concept.

Continue reading ‘Making prioritisation decisions with the “Iceberg List”’ »

One of the goals of Agile is to limit the amount of work in process. This means that they strive to complete features to a “done” state before starting out on another feature. Agile teams minimize the work in progress by working in small batches in each iteration, and moving each feature through to completion by the end of the iteration. Thus, the work in progress never exceeds the size of the iteration backlog.

Some teams go a step further and limit the work in progress for each state in the workflow. For example, they might say that only two items can be in development at a time. If the queue is full, then the previous step in the workflow waits until a development slot is empty, at which point they pull a card from the previous stage. The idea behind doing this is to ensure that the input doesn’t exceed capacity, for example by pushing more stories into development than there is capacity to complete them.

We blogged about this kind of development way back in 2007. Read it here. For more details, do read the original article on Kanban in Action.

Setting WIP limits in Silver Catalyst

Continue reading ‘What does a Work In Progress Limit mean?’ »