Carl Bruiners Agile / IT Development Consultant

22Jan/120

Identifying an Epic using apple strudel

I recently had a work trip over to Stutensee in Germany, working with a team wanting to investigate the benefits of Agile.

One of the team members asked me to explain the difference between an Epic story and a non-Epic story, to help me explain the differences I referred to a very, very good Apple Strudel I ate the night before at a local bar.

I explained that if you had a family size Apple Strudel that you wanted to eat, would you attempt to eat it in one? or break it up into managable sizes? Hopefully the anwser to this is obvious (for those who it is not, its the second of the two). Now imagine a story that is 'family' sized, too large to 'consume' in one go, which we refer to as an Epic Story, instead of attempting to complete the whole Epic Story in one, you break it up into manageable sizes.

I wanted to share this example with you in case you are fed up with the 'Epic' book / chapters explanation :-)

30Jun/112

Cone of uncertainty

Cone Of Uncertainty

Cone Of Uncertainty

Above is a cone of uncertainty, this image demonstrates how larger stories come with greater risk when not broken down further.

Small stories between 1-3 pt’s shouldn’t have a grey area because for the team to know that a story is so small they should have a good grasp on what is required to deliver that story. I have placed the 5pt story on the line border of having grey matter, as though 5pt stories are of a size where the team should know whats required to complete the story, I have found in practice that this is not always the case and often 5pt stories end up being more like a 6pt’ish story :-) .

As the story sizes increase, so does the grey area, and the grey area is not directly relational to the ideal inner cone. Get your scrum master to keep track of estimations, the actual time taken to deliver and from this you will be able to calculate your teams multiplier for the ‘grey area’. You can then use this in your sprint planning sessions as a safety buffer.

How do you minimise the ‘grey area’? Due to the nature of large stories it is not possible to remove the grey area completely, but you can utilise methods to reduce the ‘grey’. Having well defined stories and story acceptance criteria all help reduce uncertainty around a story. Though I’d rather spend time out of a meeting, if you have a 10 pt story and your grey area multiplier suggests a 3pt buffer, but a meeting would only take 30 minutes to help add clarity to your story, do the meeting as this may reduce the 3pt buffer. Do all that you can to reduce the grey area, but accept that you will never be in a position to completely remove this grey matter.

30Jun/110

Improving Sprint capacity planning – The safety buffer / net

If your team consistently struggles to meet their sprint commitments because they are over optimistic with their story estimations, try to create a safety buffer or safety net.

Often teams try to create a safety buffer by only filling their sprint backlog to 60-80% of their capacity, though this approach is reasonable it is not very flexible or accurate.

Instead if we measure the uncertainty around estimated story points and use this metric to determine how much of a safety buffer we need to put into place, this gives us tighter accuracy and improved burn rates.

To demonstrate this (please note this excludes any JDI, BUA, etc..);

Team A has a velocity of 20 pts per sprint, they are planning to include stories made up of ten 1pt stories and five 2 pt stories. In this case we know that for the team to know an item is a 1pt or 2pt story they must have a clear idea of what is required to get the job done and the cone of uncertainty is virtually nothing. Based on the size of the stories I would recommend either no buffer or a very, very small one.

Team B also has a velocity of 20 pts per sprint, but their stories are individually larger in size, they have a 10pt, 5pt, 3pt and two 1pt stories. As there is a element of uncertainty surrounding the 10pt, 8pt and 5pt stories, I would recommend that the team builds in a greater safety buffer than Team A as there is an increased chance of there being more unknowns that will occur whilst the team is working on these larger stories.

How do we determine what the size of a safety buffer should be based on the stories being considered for a Sprint? This would require the Scrum Master to keep track of the teams points estimations and then at the end of a sprint note how big an item of work actually was, you then can use this figure as a multiplier for future stories of the same size.

For example if when a team plans a 10pt story, they actually take 12 points worth of effort in Sprint 1, then in Sprint 2 they take 14pt’s to deliver a 10pt story you have a multiplier of 1.3 for a 10pt story. If the team selects a 10pt story in a future Sprint your safety buffer would be 3pts.

6Apr/113

Scrum Bargaining Board

An interesting discussion with Simon Cromarty, aka the Agile Pirate, on ways to help protect a team from over committing to more than their capacity for a sprint.

Simon then told me about a bargaining board.

What’s a bargaining board?

The product manager lays out the stories they want delivering in the next Sprint. Each card is placed on the board and as long as they do not overlap or hang over the boundaries of the board these stories are suitable

The task cards that are used on the board are relatively sized according to their point size, for example a 5pt story will be exactly half the size of a 10pt story (a personal favourite would be to have a 10pt story sized closer to 12pts).

After some further thought, I began to consider further model improvements. Instead of having just one side of the board for the team, make it double sided with a divider line. Allow the Product Manager to set out additional cards that won’t fit on the PM side of the board, this will allow teams to engage in negotiation conversations;

‘If you would like, instead of doing this 10pt story we could fit in that 5ot (or 7pts) and five of those 1pt stories?’

I would be tempted to make a story that is 10pts in size larger than that of two 5pt stories. So in reality a 10pt story could be replaced with 12pt’s of smaller stories. The reason why is because larger stores run a greater risk of being estimated incorrectly. This also allows greater flexibility in the negotiation between the PM and team.

Scrum Bargin Board

Scrum Bargin Board (click to enlarge)