It’s often not as easy as it seems, but this is how I find it should work.
You've a bunch of functionality you need to get done. You try and capture it. Maybe you've post-it notes, A5 cards, or maybe you write each separate bit onto a Trello card.
Hopefully you've all the relevant stakeholders in the room, and it’s not just your tech team, but a product owner as well.
Maybe those (Trello) cards, go into an icebox or ideas column on your kanban board? Perhaps loosely grouped together, and in a priority order.
Then you start to flesh out those outlines as Stories. You’ll probably use a format like:
So That:
As A:
I Want To:
(Though it’s perfectly valid to rotate the ordering, as many people do).
You’re trying to capture the unit of functionality with the ‘So That:’ i.e. Register For The Super System. Whilst with the ‘As A:’ you’re capturing what type of User will perform this task. i.e. Website User, or Warehouse Manager. In the ‘I Want To:’ you may list the high level actions, such as ‘Enter an email address, and password’
Optimise for readability and sanity. They should be concise, yet self-explanatory. You may want to put a summary of the ‘So That:’ as the card story title in Trello/Redmine/Mingle or the tool you’re using to manage your project.
Here’s an example of that in Agile Planner: https://agileplannerapp.s3.amazonaws.com/screenshots/agile-planner-kanban-board.png
Acceptance Criteria
How do you know a Story has been done? Well, your acceptance criteria are completed. If the acceptance criteria can be structured in a way that allows for easy testing, or perhaps even copying into a test script then so much the better. A story should not enter development without acceptance criteria.
Some may also wish to add extra information to the story, such as database fields, or elements of the architecture that they think will be useful.
Story Points
“Ok, so what’s next? Arn’t we done yet?” You should try and estimate the complexity of each story. Some are going to be trivial, and that’s where your 1 point stories come from. Perhaps something is too complex to even contemplate, and needs breaking down further? If you’re using the fibonacci sequence (of 1,2,3,5,8,13) then you may indicate that this story is an epic, by giving it 8 or 13 points. They shouldn't go into development until broken down, and more research has gone into them.
Of course, there’s an argument that if you use numbers people will try and equate this to time, when we’re dealing with complexity, so perhaps you can use alternatives like the sizes of T-shirts; Small, Medium, Large, Extra Large and XXL (For instance).
Prioritisation
Ok, so now the Product owner or someone outside the tech team has enough information to prioritise the functionality according to the business needs. The highest priority item should be placed at the top of a backlog /priorities column by the product owner. The idea being that the development team will (ideally) pick from the top of this column.
I say ideally, as technical dependencies often mean a story needs to go further up the priorities than the product owner thinks. Though you can try to explain this in the body of the story!
How Many Stories In A Sprint
Almost a million dollar question really, alongside when will it all be done?
However, the theory is that if you've run a few sprints, you should be able to average out the number of story points, and then estimate that this sprint is about 20 points (for example), and pick about that level as the team’s velocity, all other things being equal.
You should measure the number of stories, that are fully done. This maybe that they've gone through prioritisation, development, testing and acceptance by the product owner, or maybe you like to extend your done definition to being available to end users, i.e. deployed.
It’s not a precise science. And only applies if you've run a few sprints. Use the velocity as an approximate indication of how many stories to put in a sprint. After a few sprints a burn down chart maybe useful for estimating when the backlog will be complete — though it’s fair to say there’s bound to be additional stories added to the backlog!
The velocity will of course vary due to illness, number of members on the team, and how familiar people are joining the team with the technology, or existing architecture. You should keep the sprint sizes the same! 2 weeks works for many, though some very familiar teams can make 1 week work.
Ok, so that’s it. My thoughts on how to write stories, and plan a sprint. I’ll try and extend this as I get comments, and add in some further external references on how you read more on this topic.
Cheers,
Ian.
Follow Ian on twitter or send him a message.
