Keeping in lane – optimising Stories for “swim-speed”

It’s always interesting to find something your team has independently adopted as good practice is also more widely discussed as best practice.

This happened recently to me, in the Scrum team I work with.  For those not familiar with Scrum, it’s a framework used in Agile development, and more info can be found  on Scrum Alliance‘s site.  We’ve been doing Scrum for about 9 months or so now, although the teams were reorganised about 3 months ago.

In an attempt to improve the effectiveness of our teams, we’ve recently been looking at implementing elements of Kanban on top of the Scrum base, to try and apply more Lean thinking to the underlying Agile process.  This approach is sometimes now referred to as “ScrumBan”.

During the retrospective meetings at the end of each sprint, we had been reviewing the relative size of stories we were doing in our sprints, as we suspected there was some correlation between the distribution of story sizes and the overall success of the sprint.

To give some background, our team has a velocity of about 55-60 story points in a 2-week sprint.  In line with generally accepted Scrum practice, we give our Stories a point value, representing the overall complexity and “size” of the work involved, on a Fibonacci-based scale.

Working from this, we noted over the course of our first few sprints with the new team that we seemed to be more effective when dealing with stories with a “mid-range” value of 3, 5, 8 or 13 points (corresponding to around 5-25% of a sprint for us), rather than the smaller ones (0.5, 1 or 2 points) or the larger ones (21 points and above).

Thinking about this, it did make a certain amount of sense.

The overhead and background work needed to get a story set up and progress it doesn’t seem to vary linearly, so a 1-pointer will not take 20% of the overhead of a 5-pointer – it will generally take more.  This means that there can be higher overheads per point of value actually delivered when dealing with stories at the very small end.

Conversely, we were also finding that once stories got above a 21 (which represents about a third of a sprint’s value in one story), there seemed to be a significantly higher risk of the story not being fully defined and there being areas of uncertainty that were openings for scope creep, which sometimes caused issues with getting the work accepted by the client as Done.

Both of these issues were given even more importance by the implementation of “swim-lanes”, which are a way of limiting the amount of Work-In-Progress (or WIP), a key objective of Kanban.   An explicit policy was introduced for the company whereby a team should never have more than 3 “lanes” of WIP on our scrum board open at once (with no more than one Story in each), and any breach of this required approval from the Directors.

A Story could not be removed from a swim-lane until the client had accepted it as Done, so the focus came down very firmly on getting early UAT feedback and turning this around to get the lane clear for another Story.

This thinking is informed by the Theory of Constraints and the idea that you can improve the flow of work through the team by limiting the WIP and focusing on getting Stories through to being accepted as Done individually as quickly as possible, rather than doing a lot of work on several stories at once, and there then being one or more bottlenecks to getting these approved.

The way I personally visualise this is as “swim-speed” – how quickly a Story can be “swum” through the lane and out the far end.

If the Story was too small, then it would potentially spend more time waiting whilst the client reviewed it and signed it off than it actually took to do, blocking the swim-lane for that additional length of time.  If there were a sizable number of these small stories, that presented a risk of whether they would all make it all the way through to being accepted as Done within the sprint.

If the Story was too large, then it would potentially be occupying the lane for the majority of the sprint before the client was able to finish providing UAT feedback, which again risked it not making it all the way to accepted as Done within the sprint.

In both these cases, the swim-speed had been reduced.

Given this, we made an unofficial team policy to try and keep Stories within that range of 3-13 points – anything smaller than that, we would look to see if it could reasonably be combined with other Stories in a logical way that still provided value to the client; anything larger we would look to see if it could be broken down, again whilst keeping to stories that delivered real value.

In this way, we were looking to maximise the value of stories that could be accepted as Done by the client within a sprint, and hence the all-important cashflow for the company!

Lo and behold, having decided on this off our own bat, I did a bit of reading around online (particularly looking into other teams that are practising “ScrumBan” and other Scrum/Kanban hybrids) and discovered that plenty of other people have had the same “brainwave” – although often quoting different ranges of points, Scrum being what it is and these being totally team-dependent.

Now we just have to hope that it’s a case of great minds thinking alike, rather than fools seldom differing…

One thought on “Keeping in lane – optimising Stories for “swim-speed”

  1. flowchainsensei July 9, 2012 / 10:16 am

    Nice post. You might like to take a look at Goldratt’s early work in “solving” the manufacturing batch size dilemma by separating “processing batch size” from “transfer batch size” (early example of Evaporating Cloud, btw).

    – Bob

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s