Making the shift to story-driven development can be a real head-scratcher. What should a story contain? Who should be involved in writing one? Here are some guidelines to help you get started.
I'm assuming below that you're following Scrum or something Scrum-like. If you're using a different Agile methodology, most of this should translate without much trouble. If you're stuck with Waterfall or RUP, you have my sympathies -- I'm honestly not sure how well story-driven development fits outside the Agile world.
Why write stories?
A Product Owner rarely cares that you've added a button to submit an order -- not unless the code to process the order, take payment, and write it to the database is also there. They care about being able to place an order, not about how the ordering system was implemented.
Stories form a complete, deliverable unit of work. They give you a way to communicate project progress to the business in terms the business actually understands.
Stories also make it easier to commit to work for a sprint: you can estimate the complexity of a feature and, based on that, the team can tell whether they can realistically finish the story in the current sprint.
Stories generate conversations. They help specify exactly how a feature should behave, so the team knows what they're aiming for.
And stories help you focus. If the team has committed to delivering a story about placing an order, they're not going to wander off and build a user feedback system. (And if they do, they can be gently steered back to the goal they committed to during sprint planning.)
When should a story be written?
Feature requests arrive constantly, so it's useful to have a regular meeting for writing and estimating stories. I suggest a short session at the end of each sprint to handle the work that arrived during that sprint. This meeting will typically last less than an hour.
At project kick-off, you'll have more features to estimate than usual. Plan two or three meetings of one to two hours each to get through the initial backlog.
It's always handy to have more stories ready than just what's in the current sprint -- if the team finishes early, they can pull in additional work.
But try not to overdo it. Writing stories is valuable, but working software is more important.
Where should stories be written?
Nothing complicated here: you want somewhere you can focus with the Product Owner without interruptions. Find a quiet room away from the work area, or head to a coffee shop.
Who should write a story?
Short answer: everyone. The Product Owner, Scrum Master, and the Scrum Team.
How should a story be written?
The team talks about the product and identifies a specific piece of functionality to work on -- say, the ordering system mentioned above. The Product Owner, Scrum Master, and Scrum Team then define a set of scenarios that detail how that functionality should behave: What happens when the store is closed? What if someone enters an invalid credit card number? The list doesn't need to be exhaustive; it just needs to be representative.
The scenarios and the feature description are captured in a document. This can take many forms, but here's how I write them:
Feature: Place an order
In order to get goods from our online store
A shopper
Should be able to place and pay for an order
Scenario: The store is closed
Given the store is closed
And I have three beachballs in my shopping cart
When I submit my order
Then the order should be accepted
And I should see "Your order will be processed when the store opens at 9am"
Scenario: An invalid credit card number is used
Given I have three beachballs in my shopping cart
When I fill in "credit_card_number" with "MONKEY"
And I press "Pay"
Then the order should not be accepted
And I should see "Please enter a valid credit card number"Once the story is written, everyone on the team except the Product Owner estimates its complexity. Based on current knowledge, they assign a point score that shows how complex it is relative to other stories. It helps to use a fixed scale -- something resembling the Fibonacci sequence works well. I use ?, 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, and infinity. Zero means trivial. Infinity means the team thinks they could never complete it. A ? means they don't have enough information yet -- it might be estimable after more discussion or a short, time-boxed development spike. One of the best ways to run estimation is to play planning poker. I have a set of planning poker cards for this.
It's also useful for the Product Owner to assign a business value to each story, even though business value is notoriously hard to quantify. I suggest values of 100, 200, 300, 400, 500, 600, 700, 800, 900, or 1000 to rank stories relative to each other. The Product Owner shouldn't be influenced by how complex the team thinks a story is -- they're rating the value to the business of delivering a capability, regardless of the effort involved.
For both complexity and business value, there are no in-between values. Don't allow estimates of 25 if it isn't on your scale, or you'll spend forever arguing whether something is a 24 or a 25. It's an estimate. It doesn't need to be exact.
Business value and complexity can be revised whenever new information surfaces, so it's worth briefly reviewing existing unimplemented stories while writing and estimating new ones.
After a story is written, it goes into the product backlog.
What happens to the story after it's added to the product backlog?
During the next sprint planning meeting, the Product Owner, Scrum Master, and Scrum Team meet to set a goal for the upcoming sprint. This goal is what the sprint's success will be measured against.
After setting the goal, the team discusses which stories contribute towards it and decides what they can commit to delivering, based on the complexity estimates. Stories with high business value should be preferred over those with low business value -- the aim is to deliver the most value possible each sprint. There may be some negotiation with the Product Owner if they'd prefer certain stories over others, but the team shouldn't be pressured into taking on more than they can handle.
How much complexity a team can handle in a sprint should be based on how previous sprints went. Every team estimates differently and has different strengths, so this will vary widely. During the first sprint, pick a sensible but somewhat arbitrary number of stories and see how it goes. If the team finishes early, they can always pull in more work.
How do I know when a feature is complete?
Since a story represents a feature, the feature is complete when you can do exactly what the story describes. Try walking through it yourself. When you can follow every scenario in the story, consider the feature done.
If you're using Rails or Ruby, check out my article on story-driven development using Cucumber, which shows how to turn a story into an automated test.
What happens if a story doesn't get completed during a sprint?
Scrum is all about delivering working software, so if a story isn't complete, it shouldn't be part of the sprint deliverable. If your developers are working in a feature-branch pattern, this is straightforward: just don't merge the incomplete feature into the release branch.
The work that's been done doesn't necessarily get thrown away, though. It can be used to reduce the story's complexity estimate for the next sprint. Just bear in mind that this reduction is somewhat time-limited -- as development continues, the cost of keeping a feature branch up to date with trunk starts to add up.
What happens if a story is too complex for one sprint?
Stories that contain more complexity than the team can handle in a single sprint are called Epics. These can't be accepted for a sprint because they wouldn't get finished, and the sprint deliverable would show no progress. We should always show progress.
Epics should be discussed with the Product Owner. They often describe more than one feature and can be broken down into smaller stories, each deliverable within a single sprint.
Running into Epics is completely normal over the course of a project.
Any other questions?
The above covers the questions I've been asking myself over the past few days. If you have others, please ask in the comments or email me and I'll do my best to find an answer.