Sit by the fire, grab a cocoa, I want to tell you a story…

Actually, this is probably the worst kind of story there is. It’s short and to the point completely bereft of poetic license or intrigue. All the main characters are very clearly defined and what they do is almost robotic when you read about them. It’s a simple story without any kind of sub-plot and to be brutally honest, could have been written by a five year old.

This story is a user story. How’s your cocoa?

Software projects often fail the moment someone, somewhere decides that he or she wants something building in code. The main reason for the high rate of failure at the first hurdle is because it’s actually quite difficult to describe to someone what you want built. To be more precise, it’s hard to define what you want built within the usual constraints of time and money to a group of people who are all experienced in the business and have some great ideas themselves about how things should be done. It’s also very hard to know everything about your big idea up front. Actually, it’s probably impossible, but that never stopped people trying through approaches such as the Waterfall model.

Enter Agile.

Done properly, an Agile approach to software development is absolutely brilliant. It is flexible enough to allow changes to be made as things progress. It is constantly evaluating itself and therefore has a kind of self-correcting mechanism built in. It throws up problems very quickly so that they can be dealt with as soon as possible. But here’s the real rub – An Agile approach to software development will make your programmers THINK differently. Instead of “Right folks, we’ve got four months to implement XYZ”, your Scrum Master stands in front of you every morning, points his biro at your chest and asks “What are you doing today which means we will deliver ABC by a week on Tuesday?”.

“A week on Tuesday!!?*#! That’s like ten days away!! What are we supposed to be able to build in ten days!!!???”

I’m glad you asked.

By working in small, bite-sized chunks, complexity is broken down. Divide and conquer. But when we say delivering ABC by a week on Tuesday that doesn’t mean just checking in the code, it means having it ready to ship having passed all it’s QA hurdles along the way. And THAT means you’d better be damn sure your code works (and hasn’t broken anything else!) and the only way you’ll do that is by testing it.

But we digress slightly. In order to deliver bite sized pieces of work we need a simple definition of what we are required to build. In Agile parlance, we need a user story. This story should be written by a product owner or other similar stakeholder but who ultimately is responsible for delivering business benefit to, well, er, the business. The user story is taken from a Product Backlog and shown to the development team in a Sprint planning session so that, collectively, the team can estimate how much effort is required to deliver. This step is crucial to setting out on the right foot. All members of the development team have equal rights. There are no prima-donnas here and similarly, this is not a place for shrinking violets. It is vital that, as a team, everyone is happy with any commitments made to deliver work because by making it a team commitment you start to build a sense of team-work and camaraderie and, very importantly, a sense of owning the delivery. Also, during Sprint planning a good team will discuss, ask questions, probe and analyse what they are being asked to make sure that they can deliver it. They should be looking for weaknesses in the story which might cause it to fail. Over time, the team should be able to gauge the impact of a story on the rest of the system and again sanity check that what is being asked for is correct. If a product owner ‘fesses up to not having all the information then it is well within the teams rights to fire the story back until it is ready. This is one of the great safety-nets of Agile – On a regular basis, the people who are going to actually build the software get to ask pertinent questions about it’s intended use. Problems found in these early stages can save a business fortunes!

If you as a Sprint team can’t commit to delivering something, don’t

Here’s another, very important point to make about Sprint planning. If a team feels, for whatever reason, that it cannot commit to delivering a story then it should feel comfortable saying so. Too many software projects fail because people over-promise and under-deliver. In Agile, if you as a Sprint team can’t commit to delivering something, don’t. Typically, the business people will start to freak out when this happens, but why should you commit to something you don’t believe in? Ultimately, your reluctance to take on a story comes from a gut instinct that something is not quite right. Better to ask nasty questions now rather than when the code is live and 3 million users are hammering it.

So how does a team “know” if they can commit to a story. Here’s where things really get cooking. When a team is asked to deliver a story, the first thing it will do is “estimate the effort” involved in it. Typically this is done on a points based system whereby a story worth 1pt is simple but a story worth say 5pts is more complex. Points are simply a matter of relative weighting – It is very important that points do not correspond to man-hours, days, lines of code or anything else tangible. A simple planning scenario might be:

- PO: How big do you think story ABC is?
- Person 1: 5pts
- Person 2: 5pts
- Person 3: 8 pts
- Person 4: 5 pts
- PO: Why do you think 8pts person 3?
- Person 3: Well, because ABC is like story XZY which was also 5pts but this time we’ve got twice as many acceptance tests to write.
- Persons 1,2,4: Oh yea, good point, I’ll up my estimate to 8pts too.
- PO: Ok, fair enough. 8pts it is then (usually followed by some grumbling because the estimate as increased).

You get the idea. Also stories that are too big (e.g. >10pts) must be broken down into more manageable sizes until finally, the product owner has a backlog of prioritised stories which are then drip-fed into the development team at a rate they can manage.

For the first part of this max-strength web service series, our initial user story will be:

**Save Blog Details**

*(estimate 8 points)*

“As a user of the blogging web service, I want to be able to save my blog details to a database.”

Ok, so now delivering ABC a week on Tuesday isn’t sounding so terrifying.