Quote Series Part 3 - Stories

This is part three of the series, to see what this series is about, click here.

Quotes on "Stories"

Devalue the dollar - story points should be small, 1 pt - ObjectMentor coach

Stories add functionality, not technical layers. - ObjectMentor coach

If all stories are less than 5 days, we might not need a task breakdown. - ObjectMentor coach

All stories should be small enough to be delivered in less than a week. - ObjectMentor coach

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

When is a story too large?

Peter Steven's posted on the Agile Software Development blog today on the topic of "When is the story too big?" It's a really good article if you are on a team having trouble with that single story that deep-sixes the entire iteration.

Some of his points are:

• Past Performance is a good guide to future performance
• Stories should be small compared to the size of the sprint
• ‘How to demo’ makes the complexity clear
• Splitting Stories which are too big

On the second point he states:

My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

I actually took this a step further in my comments:

I would decrease your 40% further.... I am a strong believer in MMF (minimal marketable feature) and encourage items that can be broken down smaller to be. If something can be built and marked DONE in a day, that is better. Remember, sizing allows for change in scope and priority mid-iteration if needed. Large stories block this.

Thus, my rule is around the 25% mark. If a story will consume more than a 1/4 of the resources in a sprint AND it can't be broken down further, then I call for a spike. Use the spike to R&D the riskiest parts of the story and flush out the demo/acceptance criteria. Timeboxing the spike to 10% of the sprint forces re-evaluation before creating a huge time sink (allowing time to refocus 2nd spike in the same iteration if necessary).

The outcome of this timeboxed "spike" should be a more clearly defined, lower risk, and possibly broken down set of stories. Containing the work to a timeboxed spike insures the team continues to deliver other stories in the meantime.

Also... these stories should be tackled early on in the release cycle. If you wait until the 2nd to last sprint in the release cycle, your risk will probably cause you to miss it.

A lot of people forget about risk management in agile, I believe that proper story sizing is part of the risk management that teams must be accountable for when becoming a self-empowered, self-managed agile team.

Your thoughts?

Create a Proper Estimate Scale...

Tuesday I pointed at Jim Schiel's article about using an abstracted story point scale instead of calendar time (days/hours) for estimation. This morning I read a new article by one of his colleague's at Danube about their issues with their current internal estimation scale.

So, the question is, how DO you come up with a good abstract scale? Here are the main points I believe you need to address when attacking this discussion -

• Atomic unit of measure - the unit of measure needs to be atomic. This means that a value of 2 needs to be 2 times bigger than the value of one. A ten is 10 times bigger than the value of one. Why? so that when you know your team's velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
  
• Restrict allowable numeric selections - don't allow just any old number to be assigned to a story. Poker planning estimation decks can't contain every number between zero and one thousand, and you don't want it to. Human brains are very bad at estimating. The larger the estimate, the larger the error. It is easy to state that something will take 1 minute to do... it is very hard to state with confidence whether something will take 60 minutes vs. 62 minutes. The higher your number, the wider the gap between confident values. Most teams use a doubling sequence (1,2,4,8...) or a Fibonacci sequence (1,2,3,5,8,13...). When estimating, you are not allowed to pick a number that doesn't exist in the sequence. Why? it is a waste of time to watch your team bicker over the 12 vs. 13 estimate value on a story when their estimation error is larger than the delta between the two sides of the debate.
  
• Create non-numeric selections - not all estimates can be covered by a value on your scale. Most poker planning decks include a few others. Examples: Question Mark (I don't understand enough to estimate with confidence), Infinity (I understand but it will take longer than we will ever have), Coffee cup (If I don't get a bio. break first, then my estimate will be whatever you want it to be), Zero (it can be done quicker than it will take to have this conversation). Why? This facilitates the conversations that planning and estimation need to flush out. Remember that estimation is not just about predicting, but also about understanding and committing.
• Pick a reinforcing name - pick a metaphor that will invoke interest and understanding. Many people call them points, but some use more interesting terms. Examples: headaches (bigger is bad), donuts (reward I'll get for delivering), dings (times I hit a bell when I deploy), dukets, dolla, goats, bricks, cans of jolt, etc. Why? It not only engages a team, but can put focus on a positive (or negative) part of the process that needs to be used as motivation.
  
• Allow adaptability - remember, this is an abstract scale. It can be adjusted. If after two weeks you find yourself using decimals because you need units under one... then shift your scale. I've done this twice and found two good options. Add a zero (multiply by 10) so that people don't lose reference to the old scale and can transition with ease, or make up a new scale and spend an hour quickly re-estimating the whole backlog. Why? When people have to think about what a value means, then they are losing their ability to do comparative estimation.
  

Feel free to add your comments about other concerns that need to be covered.

Note: If you are interested in other posts about why to use story points, I've also posted about it myself here and here.

Story Estimates...

Story estimates should be estimated in story points... not hours. I'm a strong believer in this. I have been ever since I went through my Agile "conversion" at Siemens Medical. The formal part of my education was mostly provided by Jim Schiel.

From a recent post on the Danube blog by him:

If your estimates are consistently incorrect, you are perfectly predictable.

Click through to read the full post.

RP: 10 activities of PO

Repost: From Jack Milunsky on the ASD blog, post about the 10 activities of a Product Owner. Bullets summarized here, read full post for details.

1. create/maintain product backlog
2. prioritizes backlog
3. assists with epics->story breakdown
4. conveys sprint/release goals
5. represents, interfaces, engages customer
6. participates in standing and sprint meetings
7. accepts/rejects sprint deliverables
8. can redirect team/project with each sprint
9. communicates status externally
10. can terminate sprint early if drastic change is needed

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

INVEST in your backlog...

Backlog Items are a unit of work with end to end business value being planned, implemented, and delivered through our process. They should attempt to be:

• Independent – so that it can be reprioritized without dependencies
• Negotiable – a starting point; everything cannot be known up front
• Valuable – the story should communicate value to a user or customer, not the tasks or deliverables
• Estimable / Small – fits into one or two sprints for confident estimation and management.
• Testable – There has to be a way to verify you have delivered that value, if not with a true test or metric, then with an acceptance test by the customer.

This concept isn't something I created, but I was reminded of it when I ran across this post today on Agile Software Development about the six good features of a user story.

Nail, meet Hammer....

I've touched on the topic before:

• What do you do when you find bugs after the story is closed or the sprint is over?
• How do you split stories, and when is it cheating because you are simply using it to squeeze them inside sprint boundaries?

Well, Jeff Langr tackles a similar question. Complete Stories, not Iterations. Nail, hammer, bang. Repeat.

Figured it might make sense to hear it from someone else if you haven't gotten the message yet. If you have, then here's another source to use when explaining it to someone else.

Splitting a story...

An interesting conversation in the VersionOne user group sponsored this post:

When should a team split a story?

Good time to split a story-

• Story -> Allow user to login
• End of sprint -> The user can login by manually typing username/pwd, but system won't remember them the next time they return.
• Outcome -> Release software as is and split story into "User can Login" and "User can login without having to re-enter credentials next time." Get credit for first story but not second story.
  

Bad time to split a story-

• Story -> Allow user to login
• End of sprint -> Stored procedures are done, but UI isn't.
• Outcome -> split story into back-end and front-end work to get credit for work completed. Let DB move on.
  

This is bad because it can't be delivered. It destroys the "functioning software" line in the agile manifesto.

The team can't take credit for work unless it is "done" and adding business value to the user/customer.

These examples are over-simplified for this conversation, but many times it is not this black and white. Unfortunately, this second approach is done way too many times.