Project documentation is often an area I see companies struggling with when it comes to Scrum. A simple way to remove this major impediment is to use your user stories to drive your more traditional functional specification and for your techie stories (not user stories) / tasks to be used for your technical documentation. For project imitation I find it best if the product manager can supply;
- High level brief – No more than 1-3 paragraphs
- High level goals – 1 paragraph with bullet points per feature
- Acceptance criteria – based on the high level goals, often a high level goal will generate multiple acceptance criteria. A validation rule, if you have a high level goal with no acceptance criteria, then it is not deliverable, so either remove the high level goal or change it so that it can have acceptance criteria.
There is often a need to document every aspect of what is to be built, but the reality is we know that often adopting this approach means that what we expected at the beginning of a project is not what is delivered. Heavy upfront documentation will not promote lateral thinking, and allow either the business or supplier to deliver the most suitable product for market.
A user story defines the requirements of the business and is written by the PM along with a BA (if available / possibly the same person), the user story is then broken down into individual stories that can be delivered against, which in turn is broken down into individual tasks.
Sounds simple, but in practice it is often not achieved. If you don’t break down User Stories you’re always working against Epic scale stories. It is critical to break down user stories into multiple stories so that each story is deliverable within an iteration (or if using Kanban ensures it can fit into the swim lanes).
It is important to break down stories into tasks so that you have a clear vision of what needs to be achieved to deliver the story. Having tasks also allows us to understand during an iteration how much time is remaining. Story estimations are finger in the air stuff, in particular if you are using relative points as your measurement, task hour / day measurements helps us to understand the actual remaining time against the original story estimation. Long term this will help improve your team’s ability to better estimate both user stories and stories.
On a side note, even though acceptance criteria is only a must have for user stories and stories, I also encourage teams to have acceptance against a task. Doing this increases QA throughout the whole of the process.