Carl Bruiners Agile / IT Development Consultant

Using User Stories / Stories and Tasks to feed traditional document centric models

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.