Effective User Stories

Introduction The product backlog is the root of the scrum process. Ideally, every piece of work we do should come from the product backlog, have been well written with acceptance tests that adhere to the INVEST acronym. If the business wants a piece of work done, a user story should be created and added to the backlog.The better the user stories are on the backlog, the better chance development have of estimating how large they are and how long they take. This makes creating a roadmap and release dates for the software we produce MUCH easier!

I want a TPS report! So, the boss wants a new report. He’s a very busy guy with his head in a lot of places but has identified a need for a new report.“I want a TPS report, please put it on the backlog!” the boss asks the product owner.The product owner would then put this story on the bottom of the backlog and mark its size as EPIC. This means it’s too big and ambiguous to estimate now and needs to be refined. At this point the story could be better defined or broken down into smaller stories. This is what happens next.

INVEST time in your user stories Invest is a great acronym for helping you to write user stories, it goes like this:

IndependentIdeally, the story should not depend on other stories. While this is not always feasible, it makes estimating and prioritising much easier.

Consider a story that asks for the login to a new application to be written. The login might depend on a data access layer that hasn’t been written yet. We could estimate the login story based on the assumption that the data access layer had been written. But if we were then asked to do the login as a matter of high priority, there is no way we could ever deliver “potentially shippable code” by the end of a sprint. Then, creating a story just for the data access layer doesn’t provide any visible value to the business. So the solution is to write a story as a “slice”

of all the parts needed to deliver the login.

The login story would need to be re-written to INCLUDE some measure of data access layer, even if it’s not the fully designed version.

NegotiableThe story isn’t an exact description of the task in hand. If appropriate, the business requirements, functional spec and technical spec will spell out all that. The story itself should be negotiable, meaning that collaboration needs to occur with the author of the story to flesh it out a bit and discover exact requirements with conversations over time.

Look at stories as a catalyst to start a conversation.

ValuableA story should have value. If it doesn’t then why would we bother doing it? Once the business understands that user stories are both negotiable (not set in stone) and must provide value, it is much easier for them to write.

EstimableDevelopers need to be able to estimate the size of a story, if they are unable to do this, then either it’s a lack of domain knowledge, which requires collaboration and a conversation with the story author, of it’s too big and needs to be split into smaller stories for easier estimating.

SmallIdeally, a story should fit into a sprint. Not to be delivered by one person, but by a whole cross-functional team. If it can’t, it should either be broken down further or the sprint made longer (as long as the story is INVEST). If you can’t fit a story into a sprint, then you can’t have potentially shippable code by the review!

Testable

This doesn’t necessarily mean it should have unit tests, regression tests or QA tests passed. This means that the story must have some way of someone being able to say “It’s done.” These are called acceptance criteria, more on those later.

Lets write a story

As a ...Who is going to be the intended audience for this piece of work? Often it won’t be the author of the story. Especially if the product owner has written it. This is an important step as it allows you research whether this story will provide value for the audience, or is simply a “nice to have” by the author.

“As a middle management donk...”

I need ...Here is where you define, loosely, what is actually needed. Try and make it as descriptive as possible without going overboard and boring everyone to tears. It should strike a balance of understanding between the business and the development team, so when referring to the story, everyone knows what everyone else is talking about!

“I need an online report which allows me to add testing criteria for a particular product and have a ‘pass’ and ‘fail’ button next to each criteria”

So that ...This section is where we confirm that this story provides value. Simply putting “so I can do my job better” doesn’t really give anyone any idea of what value this story provides. Something along the lines of “So I can analyse the data to enable me to make a decision on whether or not increase my bidcaps” does.

“So that, we have a digital record of all testing done, which is easily replicable and can be modified.”

Acceptance criteriaOK, so we’ve written the story well, it defines the “who”, the “what” and the “why”. But, how do we know when we’ve finished? The fact that a story is negotiable means the business could negotiate until the cows come how, scope/feature creep is certainly something that can sneak in.

So, we add Acceptance Criteria. We simply ask the business; “How do we know when we’ve finished this piece of work?”. The acceptance criteria should be a bulleted list, it could come in the form of questions that require a “yes” to know if they’re done:

● Can I add test criteria to my online TPS report?

● Can I mark each criteran with a PASS or FAIL?

Or, as a list of statements:● TPS Report has multi line test criteria● TPS Report has “Pass” and “Fail” buttons next to each critria

It would also be acceptable to reference another document:● Report looks like mock up supplied by designers;● Report data is displayed as defined in Business Requirements;● Getting to report should follow process flow as laid out in “Logging into system and

authenticating”.

This also means that the acceptance criteria shouldn’t look like a functional spec. They shouldn’t contain explicit instructions for accessing the particular feature, just whether the particular feature works.

Conclusion Writing user stories shouldn’t be difficult. The import thing to remember is collaboration with the business. Poorly written user stories with badly defined acceptance criteria make everybody’s job much harder in the long run; poker planning becomes long and drawn out, estimating is almost impossible and by the time we get to planning, a badly written user story might actually be hiding more work than we’d estimated for in the first place and our estimation was woefully wrong.

Effective user stories with well defined acceptance criteria form a solid foundation of the work we are asked to do. The sooner we know accurately what it is the business wants, the better chance we have of being able to deliver a potentially shippable chunk of code for the sprint review!