What Details?
On a recent flight, I was reading about paying attention to detail in creating a dream room for your home. Attention to detail is important whether you are decorating your house, or building software. I work with Product Owners trying to write user stories so often, I instantly thought “I need to write about user story details”.
When teams are getting started with user stories, the inevitable question is where do my detailed requirements go? I think this is especially true when I work with huge organizations in highly regulated industries.
Details are Important
I’ve seen Product Owners (especially those that were formerly BA’s) fill entire user story description areas with details. In Agile practices, that flies in the face of what the user story is meant to convey. User stories are a trigger for a conversation. User stories should convey to the developer what the user wants to do and why. Once we get past the basics of the user story, then and only then, can we add details in the form of Acceptance Criteria and other attachments (wireframes, mock-ups, database excerpts, etc).
Before I go into user stories, I want to say that not all product backlog items (PBI’s) are user stories. PBI’s may be defects, technical stories, or spikes. If you are a feature team working on a web development project, then demand good user stories. However, if you aren’t in development, or the PBI isn’t a user story, then I question whether or not there is value in trying to force folks into the user story format (As a who, I want what, So that why). I do not question, ever, that we must provide detail along with conversation in order for the work to be performed, tested and accepted.
In organizations that have component teams working on ETL (Extract Translate Load) functionality, middle tier software services being written separately from the consuming team, or scrum teams not related to software at all (marketing, sales, audit), Agile still works and stories still make good PBI’s. Just don’t force yourself into the “user story” format if it doesn’t add value.
Check out Mike Cohn’s blog here for more on “back-end” stories http://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems
Sometimes we use the Agile Manifesto as a reason for skimping on what is needed. I fully believe in “Working Software over Comprehensive Documentation”. I am the first to ask, “who is going to read all this”. However, I also ensure that my teams get everything they need in order to provide quality results. If this means the Product Owner must work harder at getting the stories ready, then that is what they do. It is their job. Organizations need to know what a big job the Product Owner has. Just because we move from a waterfall version of requirements to Agile versions of requirements doesn’t mean the job takes half the time. In fact, it may take longer. Product Owners must break down stories, get details and be present for discussions with the rest of the team during story grooming/refinement sessions, or during development. If a developer wants more details the Product Owner must get them.
Creating User Stories
What does the process look like? To go from the initial creation of the title to a fully ready story can take any number of days. How much time and effort is spent on documenting the story depends on where it is in the stack ranked order of the backlog. I would rather not put all my effort into stories that aren’t coming up in the next 2 – 3 sprints. Even though I have hundreds of titles ready to go for months’ worth of stories.
Let’s take a look at some examples
The following user story could be broken down smaller, for a start though it meets the basic user story criteria telling who, what and why, but not how. It includes acceptance criteria, and if we were in a tool, I would expect to see supporting attachments.
Title: View Order Details
Description:
As an online customer
I want to see a summary of my complete order before I hit enter or submit
So that I feel confident everything is correct
Acceptance Criteria:
User stories are a trigger for a conversation. As we have the conversation a lot of questions should be asked… and results of those questions can be noted below the acceptance criteria.
Now let’s look at a technical story for a component team not invited to share in the front-end team’s user stories:
Title: ETL Sales Report – Team GoGo
Description:
Data must be loaded into the sales data warehouse in order to provide metric reports
Acceptance Criteria:
Here is a non-IT story:
Title: 2015 Security Audit – User Access Process System X
Description:
Audit Onboarding process with HR to ensure User Access requests follow approved processes
Acceptance Criteria:
So where are the details?
In the Acceptance Criteria and associated documents! If something is missing, get it there before accepting the story into a sprint. If the story looks too big, break it into smaller pieces. Ensure you cover happy path and not so happy path options. Plaster your cube with domain models, object models, etc.