Using an agile storyboard as a scale of certainty

As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate.

Scene setting
We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts.

Our story wall (in ugly table form)
The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are only 2 extra sprints shown).

Level of certainty	<--Least certain	IN about 4 weeks	In the next 2 weeks (probably)	Sometime this sprint	In the next X days (depending on cycle time)	As previous	Sometime in the next 2 days	Probably tomorrow	Most certain -->	Guaranteed
Story wall column	Sprint N+2	Sprint N+1	Current Sprint	Backlog	Analysis	Ready for Dev	Ready 4 QA	In QA	Done	Released
Estimate type	T-Shirt	T-Shirt	T-Shirt	T-Shirt	Relative effort	Relative effort	Relative effort	Relative effort	Cycle time recorded	Cycle time recorded
Story type	EPICS (also known as feature sets)	EPICS	EPICS	EPICS/Stories	Stories (Although their could be epics hiding in here)	Stories	Stories	Stories	Stories	Stories

The scale of certainty
The certainty around both delivery and estimate accuracy increases the further to the right you move. On the left hand side, very little engineering team time is spent on the cards (the less the better). We have a brief discussion about whether something is possible and give a t-shirt estimate based on some basic discussions, but little else. This is because, this far out from the actual engineering work being carried out, there is little value in it (Card might be pulled, we'll have to do it again anyway etc etc).

Estimation
Cards are estimated in T-Shirt Sizes at the epic level, relative Effort at Story Level, and than the Cycle time recorded once the card is done (with pertinent data gathered at various points along the way). We have a scale for T-Shirt sizes (TM Simon Bristow) which we adjust as we go along and get better at guessing.

At the moment it reads:

• Small - Coupla Days,
• Medium - 3-5 days,
• Large 4-8 days,
• XL 2 Weeks (+).

We than use these measures to release plan, so a 2 week period may be able to contain 1 small and 2 mediums, or 2 larges (with one being at risk) or one XL, or various combinations therein. The understanding is that at this stage out from any detailed understanding of the cards, the estimates are ropey at best. This does still however allow for a level of release planning, with adjustments along the way.

The photo below (with names covered to protect the innocent) shows the 'Release' wall in action. The Yellow cards are the Epics (or feature sets) proposed for the upcoming sprints. We are currently in Sprint 2, and the Epci cards include stories currently underway, or upcoming. They serve a couple of purposes. To focus the team on the Demo Goal, and if they don't get completed, they can be used to reflow the cards following. You can push a story into the following srpint, and therefore you'll need to reprioritise the following cards accordingly. Either dropping some or reshuffling cards all the way down the line. On the far left is a feature set that has been pushed out of the release.

The following image shows the cross over point between the Release board and the Current sprint.
The backlog column are the Epics that have been readied as much as needed for the current sprint. If the business owner is able, they have broken the Epics down to Sotry level, however, we also have another point were this can/is verified by the team. We have exit criteria for our analysis column which is:

• Estiamted (to Relative effort level - our next scale of certainty/size)
• Scenarios written (our version of requirements - for automated functional testing)
• Card/Story size okay (i.e. is this no longer an epic)
• Tests complete (manual test cases not covered by automation)

This is essentially the stage where most of the heavy lifting is done. The story is at its most understood before development commences, and we are most likely to commit to development. This level of information gives us much more certainty over how long it will take to deliver, combined with our next step (Cycle Time) we should be able to give a much more accurate measure of how long development will take.