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

 

 

User Stories defined - notes from the XP forum

I was recently following a thread on the XP forum and one of the responses from Ron Jeffries is worth repeating here for you all to read.

 

"

Um, yes. Or as someone put it long ago, a user story consists of ...
Card
Conversation
Confirmation

The card is just a token used to pass around if one estimates, to
hang on the wall as something to be done, to move around the status
board, and so on.

It is in conversation between PO and team that the team learns what
is really meant. It is here that much of the creativity lies,
converting what the PO originally thought she wanted into the best
idea the team can come up with.

Confirmation, in the most productive teams, consists of concrete
tests, or checks, that show when they pass that the software does
what was agreed it would do. Fastest and most reliable development
seems to happen when a very high proportion of these checks are
automated.

[Some people have the impression that a user story is only #1 or
only #1 and #2. I don't agree, but that's another topic. I don't
think any of the 3 MUST be fully documented, but I do believe all
of the 3 should be well communicated to the dev team.]

Yes. The point is communication. The card serves as a point of
focus, and a status marker. The conversation builds common
understanding and agreement, the confirmation contains the details
of the agreement.

Your detailed test examples are right on point to the original
questions. The one thing that I would add is that it is perfectly
fine to write these story ideas on cards associated with the story,
or on a sheet of paper. The probably do not to be documented further
within the team, and there should probably be no one outside the
team who needs that level of detail.

If the tests are going to be automated -- and generally I recommend
that -- then the test itself serves as perfectly adequate
documentation, especially if written in a FitNesse table or a system
like Cucumber. If the tests are going to be done manually, first go
back to the previous sentence. If there are still tests that need to
be done manually, it may be worth writing them down in a test book
so that you can be sure to do them again, and again, and again, as
regression tests ... which is why automation is so important.

You recommend Mike Cohn's book, and it's definitely a good one. It
is possible to get the impression from it that you should do
everything in there, and it's probably best to do as little as
possible. Start with Card, Conversation, Confirmation. Then, for 99
percent of teams: stay there.

If you're interested in sources, here's an early description of the
ideas, and a darn good one if I do say so myself:

http://xprogramming.com/articles/expcardconversationconfirmation/

Ron Jeffries

 

"

Technical stories - are they included on the backlog?

If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.

Sprint start and stop days - what's best

Firstly, let me state that it is imperative that sprint lengths remain consistent. By all means experiment with 1 week, 2 week or 3 week sprints but once you have figured out your sweet spot, stick to it. This is important to setup a rhythm in the company. However, the question is what days are the best days during the week to start and stop sprints. Until now, I have been a big fan of Monday starts and ending Fridays. It seems to be a natural cadence and the days are logical transition points.

However, this week, there was discussion on the Scrum development forum and a number of folks are in favor of starting on Thursday and ending on Wednesday. Reasons given are as follows:

• There are often holidays on Mondays and Fridays which interrupt the cycle and therefore the rhythm.

• If sprints are a little behind and you end on a Friday, it will force teams to work on the weekends -- generally shunned upon by the Agile community.

• On Fridays, folks generally tend to glide through the demos and retrospectives and as a result there is a drop in productivity.
• Team members work from home on Fridays.

The right answer, let the team decide.

Certainly school for thought. I have to give this a try.

What's been your experience?

Jack

Remote contract workers

A question posted this morning on one of the Yahoo groups ..

" We have a Scrum team in the Silicon Valley and two contractors who work with us remotely. Although they are proficient at what they do, it has been a challenge to get them (understandably so as contractors) to be apart of the team. We have two main issues:

1) They are contractors and don't see Scrum as more than just something to do to
keep a contract.
2) Daily meetings and full conversation required for communication saturation
are next to impossible over the phone (and really poor quality, unreliable Skype
video), and despite our efforts there is a disconnect and a lack of
effectiveness felt by everyone.

Agile and Lean - Closer than you think

Sara Peyton published a really informative blog today on Lean Software development. Essentially it's a pretty detailed overview of the characteristics of Lean. The point of the blog however is to outline the differences between Agile and Lean. As Sara points out, "Agile has a different perspective from Lean and, generally, has a narrower focus".

Whilst I agree with the fact that Lean is much more broad, there are more similarities with Agile than one would expect. If we examine each of the 7 principles discussed in this blog, and relate them to Agile it's pretty obvious to me that Lean and Agile go hand in hand. Now when I speak of Agile, let me clarify what I mean.

Why switch to Agile - besides failure

Photo by: The Letter E

There's a thread currently bouncing around the Yahoo Agile group as to why organizations would consider switching to Agile. A lot has been said about project failures and there's debating back and forth as to what statistical data is out there to back a company's decision to switch.

The way I see things is that both Waterfall projects and Agile projects succeed and fail. So it's not just because projects fail that one should switch. Most certainly that's a big reason. But there's many other reasons why company's should switch. One only needs to read the Chaos report by the Standish group to realize that there's most likely a better way to do things than traditional methods. Lets face it. There were a lot of smart people behind the Agile movement and so there were reasons that they sought to find a better way.

So what are the other reasons to switch, there are many tell tale signs to look for in your organization for example and this is not an exhaustive list: