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

Doing the Right thing vs Doing it Right

Photo by: Teuobk

In a recent thought provoking blog post by Allan Kelly titled "Requirements Come Second", Allan makes the case for resolving the development process side of the business first before addressing alignment issues with the business.

It's probably one of the most interesting blogs for a while and there have been lots of good comments made. I suggest you read the full article. I guess I can't argue with the data. However I don't think it's that hard to work on both sides simultaneously. And I truly believe that the Scrum process makes it easy to address both requirements and development process at the same time assuming you are following the prescribed Scrum practices. Let me explain....

Scrum requires that you have a single Backlog of requirements and that you have a single owner of the Backlog - the Product Owner. The Product Owner is responsible for sequencing the Backlog and therefore he can't be doing this in isolation of the business. Scrum also prescribes that teams identify Sprint goals at the start of every iteration. These goals need to be aligned with the business overarching vision and strategy.

Bottom line is that adopting Scrum is going to help your company get aligned with the business and of course will help you with the development process at the same time. Additionally, I still believe that the biggest risk of all is delivering the wrong Product so I think it's prudent to deal with this side of the business as well. Why not?

I personally don't buy doing one without the other. And Scrum really helps you to address both at the same time.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

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:

Significance of Time Boxing

Everything in Scrum is time boxed - assuming you go by the book of course. Did you ever stop to wonder why?  The Sprint planning meeting is time boxed to two 4 hours sessions (One to define what you’re doing, the other to define how you’re going to do it). The Sprint itself is time boxed to 30 days or less depending on how you’re structuring things. The Sprint review meeting is time boxed to 4 hours as is the Retrospective. So what’s this time boxing about anyways?

Fundamentally, it’s designed to establish a sense of urgency and to coerce the team to focus there efforts on getting something done. This is based on one of the Agile Manifesto that suggests the best way to show progress is to produce demonstrable working product, not documentation - Wow, what a concept! That’s not to say you don’t need documentation. In many cases this is required for ISO, FDA and other standards, but documentation is just one of the artifacts that needs to get produced during the course of the sprint – it’s not the bee-all and end-all.