You are here

story

We all know that a user story should not aim to capture all the detail about a requirement or business need. It is more of a promise that a conversation will take place, the options explored and some work will be done that will deliver that business value.
One of the key things to make sure of, when writing user stories, is to have a clear view as to when a piece of work is completed. The normal way of doing this is to document a set of acceptance criteria against a user story. What we don't want though is to write a 20 page requirements document as acceptance criteria.

Story Kick-off: Why on earth would we need one of these? Well think about it for a while, you have a project kick-off, an iteration kick-off. Any significant piece of work has a kick-off before work start, and for a very good reason. We need to make sure that there is a common understanding on what it is we are going to do, what we are going to deliver and how we are going to deliver it.

Try this as a standard agenda to a story kick-off and see how it immediately improves things

Easy, write down a list of individual features and order them, job done? If only that was the case!

A product backlog is not simply all the product features, it is all the work needed to build and deliver the product. This includes all features, functions, enhancements, and fixes, all that boring engineering work, infrastructure commissioning, documentation and loads more. It is also a planning tool, letting us know what is most important to the business an gives us some indication, along with velocity, when the project is expected to complete.