Story Point accounting – I am on the fence on this one folks...or am I?

Firstly, I'd like to say thanks to everyone for the wonderful comments received in regards my writing. Frankly, I am flattered. I'd also like to apologize again for not writing more regularly. It seems like I just never get the time these days with my busy life.

The scenario I want to specifically talk about today is as follows: 

You plan a Story into a sprint, let’s say an 8 point Story, but the team doesn’t get to finish the Story. How should you account for the Story Points in the current and subsequent Sprints? Let’s just say for explanation's sake that the remaining work for the subsequent Sprint is 3 points.

Well, almost all if not all the Agile thought leaders agree that the team should not claim any points in the current Sprint. So even if the team completed 5 points worth of the Story, because it’s incomplete, the Team adds 0 points to their velocity for the current Sprint. I agree with this.

But here’s where it gets interesting. And there are definitely 2 opinions on this.

In the subsequent Sprint, do you claim all the Story Points originally assigned to the Story (8 in this example) or do you just claim 3 points?

Let me first explain why I like the first option.

Claiming all the Story Points in the subsequent Sprint is good because you actually did all the work and so from a pure “value” perspective (Value delivered toward the overall Product), this is the most accurate.

If you choose to only accept 3 points however, your average velocity actually drops lower than your true velocity. Moreover, the reason why you didn’t complete the story in the first place is because it was probably even bigger than the original estimated size –- that’s why you couldn’t finish it in the first Sprint. So if you only claim 3 points in the subsequent Sprint, you’re actually dropping your real velocity even more than just the 5 original points.

The benefit of only planning for and accepting 3 points in the subsequent Sprint is that it is the most realistic representation of the remaining effort. So your planning for the subsequent Sprint will be more accurate with a more predictable outcome I would think. Additionally, it’s a more conservative way of accounting your velocity. If you think about it, we humans are generally optimistic with our estimates in the first place so going the conservative route I think is not such a bad thing.

I posted this question to the Scrum Development forum. And interestingly, folks were divided in their opinions on how to do this. I think it was Ron Jefferies that suggested that Teams try whichever they think is best.

Personally, I think if you look at the problem from a pure Value perspective, then I think the first option is best, i.e., claim all the points in the subsequent Sprint.

If you value ongoing planning and predictability more, then I think the second option is best as you can plan more realistically based on the actual remaining effort.

Let me know what you think.

Happy sprinting

Jack

www.agilebuddy.com 

 

New Found Respect for Story Points

I gotta tell you, I have been using Story Points with teams for quite some time now. But recently, working with onboarding more than 9 teams at one company in the space of 3 months, I have learned to appreciate what Story Points really mean and the effect that they have on making teams successful.

With each new team that is getting up to speed with Scrum, the hardest transition is figuring out how to estimate in Story Points. There are many ways to help teams do this, including starting them off with 1 story point = 1 ideal day. But that's not the purpose of this blog post.

What is amazing is that with each of the 9 teams I have onboarded recently, each one consistently missed completing the planned Story Points in the first Sprint quite significantly.

In each instance, during the retrospective, I was asked...

"But we're so close to completing the Stories, can't we get most or some of the points?!"

While I am not such a radical must-follow-every-Scrum-rule-by-the-book kind of person, when it comes to Story Points, I am quite adament. You don't finish the story, you don't get any points!!! Period!

So my question to the team after that discussion is: "What could you have done to finish some of the stories?" Well, the answer to that question becomes quite obvious, and all the lights go on. The team could help swarm the top priority stories (minimize the work in progress). I have covered this before..."stop starting and start finishing" is the name of the game.

In each case, after the 3rd sprint, the teams were in the groove and the Story Points started to go up on the board.

Adopting such a hardline approach helps teams to really learn the meaning of DONE and, in my opinion, using hours couldn't get you this effect even if you tried.

Additionally, I have found that teams are quite optimistic to start out. So they typically sign up for too much work in the first one or two Sprints. This all helps to setup much more realistic plans and gets teams to a stable optimal velocity sooner.

Hope this helps.

Jack

What’s in a Story – Breaking things down

When I think back on my Scrum experiences I keep coming to the same conclusion - that the mechanics behind “Stories” has to be the most important aspect of the process. If your “Stories” are properly “designed” then you have the best shot at succeeding with Scrum.

So when I say “designed” what do I really mean?

Let me explain ….

For starters while I believe that the format of the Story is important (I wrote about this some time back that the format is not the most important thing though) when I say design I mean the careful thought given to how the stories are broken down.

Essentially, the smaller your stories are the more chance you have of succeeding. Most of the Agile thought-leaders (especially from the XP camp) are recommending small equally sized one or two day stories.

Trust me creating equally sized stories is pretty hard to do. If you can get them equally sized then there’s all sorts of benefits including tracking just by counting stories which is very easy to do.

However as I am sure you know by now I am not religious about things like this. So while I don’t necessarily prescribe to one size fits all, I do believe wholeheartedly in smaller stories are better.

Breaking down stories is hard too. I hear it all the time, “it’s not possible to break this story down any further”. But there’s always a way so in this blog I am going to give you some neat ideas on how to break stories down further.

But let me start with DON’T BREAK STORIES DOWN BASED ON ARCHITECTURE. i.e. It’s not good to implement just the GUI layer or just the DB layer. It’s important to maintain a thin slice of the feature across all layers if at all possible.

So what are some of the better ways to split?

1. CRUD – or rather Create, Edit and Delete

So if your Story is say as a sales person, I’d like to be able to create, edit and delete an account from the CRM system, then you could first do Create, then in another Story you do Edit and in another you do Delete.

2. Acceptance test criteria.

Don’t know about you but before we begin any Sprint, all the acceptance test criteria are defined and agreed to up-front for every Story. One way to pare things down is to split the story into separate Stories for each of the test criteria.

3. GUI Screens

Another way is to split the functionality by Screen boundaries or by paring down the number of elements implemented on the screen

4. Validation

You could of course choose to do data validation in the next story, that wouldn’t be such a bad thing

5. Scalability and Performance

You could choose to get the Story working, but then later refactor it for scalability or performance although this is somewhat risky. But sometimes we spend more time iterating through the look and feel of something than we do on performance so better to see what it looks like first than to see it working for thousands of simultaneous users.

6. Stubs

You could choose to Stub out certain functionality by creating stubs to simulate functionality

7. API/GUI

You could get the API functioning correctly first and returning the correct data and then later hook it up to the GUI – although I don’t think this is necessarily the best approach

8. Static vs Dynamic

You could implement the functionality using static data in one Story and then later implement the dynamic parts to the story

9. Error handling

You could choose to add the error handling in a second Story

I stopped short of ten as I am sure there are lots more ways. Perhaps you can help me fill in the rest with some of your experiences.

Thanks for reading.

Jack

User stories: Does the format matter

We are all familiar with the suggested format of a user story

"As a <role> I want <something> so that <some benefit>"

What's great about this format is that you capture a great deal of context for the developer with very little information presented. And while I believe this context is important, I don't believe the specific format is the most important thing to worry about.

First off, when you take a look at many backlogs the repetition of "As a blah ..." can drive you nuts. Second, most backlogs you see, stories are written - "As a user blah ..." and that's no value to anyone anyways.

So where am I going with this ??

What's most important about the user story is really the conversation that it generates and the acceptance tests discovered during the Sprint planning sessions where the Stories are explained. I was present in a Sprint planning meeting the other day, and although the Story was not all that well written, the understanding gained during the Sprint planning discussions was unbelievable. In fact it was such an eye opener for me. At that point, once the understanding is reached, the Story is just a label.

Now don't get me wrong, knowing the user and the benefit is great to know however in order of priority, I'd say Conversation is #1, Conditions of Satisfaction or Acceptance Tests are #2 followed by the Story format in a distant #3 spot.

Not sure what you folks think.

My 2 cents, don't get hungup on the format, get hungup on the conversation!!!

Happy planning!

Jack

 

 

Whose doing your Sprint demos

Ok, this has to be the shortest blog post ever. But just maybe it's something useful you can try. So this is more of a tip than a blog post.

Typically during the Sprint demos the devlopers do the dog and pony shows. They coded it and so they generally like to do the demos.

What we tried out at my last gig, was for the QA folks to do the demos. What's good about this is that it really shows the chickens and pigs that the loop has been closed.

As we all know, it's acceptance tested stories that really count. Code complete is meaningless. When QA is put on the spot to do the demo's they really ensure that the feature is understood and is working well. It also makes them feel important and part of the process.

Try it, even rotate the responsibility after each Sprint.

It worked in our context and may well work for you.

Let me know

Jack