Agile Requirements - Writing, Grooming, Refining

This is where it starts, without well thought out and laid out requirements the story/feature/project can be a vague idea open to diversions, misinterpretations, unending iterations within the team and international conflicts. Let us explore some of the opinions and commentaries made recently on the topic of Agile Requirements. These individual posts explore practices that can range from a single acceptance criteria in a story to overall backlog refinement.

Why Write Requirements
http://tynerblain.com/blog/2013/07/17/why-write-requirements/

Summary -
In his post "Why Write Requirements" Scott Sehlhorst takes a step back from the "How" of writing requirements to the "Why". Sehlhorst lays out 6 major reasons for writing requirements and how they fit into the Agile sensibilities. His six biggies are as follows -

• Understanding Your Market
• Sequencing Delivery
• Collaborating With Delivery
• Managing Expectations
• Improving Efficiency
• Remembering Intent

Favorite Snippet -

"Teams that ignore opportunities to get smarter about changing needs will also, by definition, build stuff that isn’t needed."

Agile Requirements Uncertainity  http://leadinganswers.typepad.com/leading_answers/2013/11/agile-requirements-uncertainty.html

Summary -
Griffiths talks about the starting from scratch projects where overall direction is not yet defined. He shows how the uncertainty allows for the ability to prioritize the highest business value items. Griffiths shows the positives and negatives of both traditional and agile requirements. It is a pretty unbiased look which recommends horses for courses, while giving a quick tour of the advantages of both approaches. He accepts that this is a "bipolar view of the world" while presenting the two ends of the spectrum.
Favorite Snippet -

" If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs." 

Cheat Sheet For Backlog Refinement
http://thecriticalpath.info/2013/11/05/cheat-sheet-backlog-refinement/

Summary -

In his November 5th post at The Critical Path blog, Derek Heuther defines a new ceremony for agile teams called "Backlog Refinement". He recommends an activity in which representatives from the management team, product owners and agile team members get together to look at work that is scheduled for 1 or 2 iterations ahead. The general idea is to start from the bigger picture to prioritize the backlog and at the same time make sure that the stories have the correct Acceptance Criteria (aka Conditions of Satisfaction) and follow the invest model.

Favorite Snippet -

"Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale."

Agile Requirements Best Practices
http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm

Summary -

Scott Amblers and associates' Agile Modeling is a great site for agile resources, especially for design and analysis. This essay describes 16 guiding principles of agile requirements. While it is a bit of information overload, it is a great post to revisit periodically. The best practices run the gambit from "Adopt Stakeholder Terminology" to "Take A Breadth First Approach". 

Favorite Snippet -

"...project stakeholders should be involved with modeling and documenting their requirements, not only do they provide information but they actively do the work as well."

Grooming The Backlog, Combing The Desert
http://jeffryhesse.com/blog/agile-mondays-grooming-the-backlog-and-combing-the-desert/

Summary -

Jeffry Hesse in his Agile Mondays series recently talked about backlog grooming. He attempts to, as Heuther does in his post, firm up the "sort of vague concept" of grooming the backlog. The act is defined as something that has been mostly the domain of the Product Owner, but should spread to be a team activity where the Product Owner is an integral part. Hesse promotes eliciting team feedback both on priorities and on story content. Hesse also provides a short list of questions that the team can be asked in order to make the act of Backlog Grooming successful. An important part of this post is the guidance regarding Technical Debt. Product owners can make the process of prioritizing Technical Debt much easier by explicitly asking questions about its existence.

Favorite Snippet -

"Continue to challenge the team as there is likely ALWAYS something that can be improved in your Product’s code. You as the Product Owner will need to ultimately weigh on if it will return the highest value to users/purchasers, but it is very important to chase these items out."