How to Significantly Improve Requirements Writing and Communication with Agile
Category:Agile Adoption,Agile Productivity,Business Agility,Organizational TransformationHow do you write and communicate effective Business requirements from an Agile standpoint?
I recently worked with a client who was interested in leveraging Agile to improve requirements writing and communication in her organization.
In the pre-call meeting for the class, she asked me, “So how do we establish good requirements between Business and IT? And how do we pass them along and not have to hear from the Business again?”
First, the good news is that there are tangible ways to significantly improve requirements writing and communication.
The second part of this question requires a bit of re-framing.
To expect that no communication is required from the business (or vice-versa) is not a realistic outcome. However, with the right structure in place, requirement communication and delivery will become a productive exercise.
So let’s dig in. Here are some ways to significantly improve requirements writing and communication.
1) INVEST in your requirements
Requirements should follow the INVEST principle. That is, they should be Independent, negotiable, provide value, be estimatable, are about the right size so that they can be implemented by the team, and are testable.
2) Use a “card, conversation, confirmation” approach to agile requirements writing and communication
The most Agile requirements are written from the customer standpoint. A great way to apply this concept to requirements is to use the “card, conversation, confirmation” format.
- Card: As a <customer> I should be able to <action> so that <benefit>
- Conversation: Review the card with development team and cover questions. Aim to have conversations to flush out assumptions and mark as ready. Move on when the team unanimously gives a thumbs up confidence vote.
- Confirmation: This is the acceptance criteria that must be met in order to sign off on the requirement. A good way to write acceptance criteria is to use a Gherkin format. Use the vantage of a particular customer/user.
- Example: Scenario 1 – Given <a precondition>, when <action>, I should expect <result>
3) Choose the right level of granularity
Requirements should zoom into the right level of abstraction for the audience in mind. Make sure to keep the overarching goals in sight. Requirements should be born from a high level purpose. They should be increasingly broken down into more bite-sized areas for execution.
All of these levels are relevant since they connect strategy to execution. The levels should connect the why to the what to the how.
- Initiatives – Organizational business goals (KPIs, Business requirements) Ie. Improve speed of content entry by 10% (Executive level)
- Features – Highest level of requirements ie. Content Management and Publishing Portal (Executive-Program level)
- Epics– functional requirements – ie. Content Entry (Program and Team Level)
- Stories – (Team Level) More detailed but (INVEST) small, independent, valuable, estimateable, testable – entail a conversation, have clear acceptance criteria. Ie. Publisher uploads new science publication document.
4) Establish up-front working agreements for better communication
Agile talks about the importance of customer collaboration. There are two types of working agreements that help improve communication between business and engineering. These working sessions happen initially up front and are revisited periodically.
Draft a Definition of Ready
The Definition of Ready (DoR) includes all things that should be included in requirements before they can marked READY to be worked on by the development team. Some examples might include:
1) Clear acceptance criteria are in place
2) The requirements include major design assets
3) The requirements reviewed and acknowledged
by the team
Draft a Definition of Done
The Definition of Done (DoD) includes all things that must be completed before declaring the requirement as DONE (or “done done”). Some examples might include:
1) The unit tests have been written and pass.
2) Test Coverage is 80% or better
3) The acceptance criteria have been met
4) The requirement has been reviewed and acceptance tested by the business owner
5) Take smaller bites
Often the pain associated with requirements is related to information overload. This is often where you may find requirements churn.
Break down requirements into smaller chunks that can independently provide business value. Leverage the INVEST criteria. Try to spend no more than a focused 1-2 hours per session to groom the top-most valuable items. Then move down the backlog of requirements and repeat.
6) Have the right people in the room
Have you ever played the telephone game? And how did that turn out?
Ensure that the right people are in the room from the get-go. The right people are those who can uncover assumptions of the requirement, or those who can help make the right decisions. Wasted time and effort will be saved in the long run.
For a product owner on a team, this meeting might include the engineering team and designers.
Or for Business Owners, this might be representatives of the financial, marketing and operations teams.
Get everyone aligned in the same room from the beginning and you have already stacked the deck in your favor.
You may find that you have trouble identifying the right people. Step through the requirement end-to-end from a customer standpoint. Try to understand the underlying systems that are in place. Some examples of systems include the Marketing system, Fraud system, Customer Records system and Billing system. From there, identify key people who represent those areas and bring them in.
7) Establish a rhythm
Practically speaking, one of the biggest challenges related to requirements and communication is that Business people in particular often have chaotic schedules, and it is all but impossible to get everyone in the same room.
Are you begging, bribing and stealing for peoples’ time? One of the most effective ways to solve for this is to establish a regular product requirement grooming cadence. So if the events are already established, attendance will improve. With a regular schedule, meetings will be shorter. If you’re a facilitator, this reduces the overhead of scheduling multiple ad-hoc meetings.
Depending on the nature of the project, a focused hour a week can work well for 10-20 person product/engineering team.
8) Visualize the work
Leverage a visual centerpiece around the work. It could be an ordered backlog, or a roadmap showing the current and upcoming features.
This will be used as a springboard to help drive collective conversations about the product. Use an easily accessible, up-to-date medium (like a shared wiki). This will go a long way to simplifying communication and alignment.
9) Hold regular product demos to capture and communicate requirement feedback
One of the most powerful ways to bridge communication and foster continuous product improvement to is hold regular product demos.
In terms of format, these demos are often hosted and led by the engineering delivery teams. The demo is delivered to the business stakeholders.
The intention is to focus on sharing the actual working solution. This activity should be informal and not require much up-front preparation. So leave the slides at home. From this, you can expect a lot of valuable collaboration to spring up. Questions and feedback from the Business can be used to shape the product backlog in the future.
What’s great about this exercise is that it’s unifying, motivating and engaging. The teams walk away with a sense of recognition and appreciation and the business has learned something new.
In Summary: Writing and communicating great Agile requirements
With the right structure in place, your organization will significantly improve on requirement writing and communication.
Incorporate INVEST and ‘Card, conversation, confirmation’. Your Business will be on its way to having clearer requirements.
Break down requirements into smaller more actionable units. Rhythmically include the right people.
Visualize your work. This will lead to a more aligned view. It will permit feedback to refine the product over time.
Finally, foster a common understanding of expectations between Business and Engineering. Establish working DoR and DoD agreements.
Now you have the structure to improve requirements writing and communication. It’s important to take action! Make a conscious effort to apply these techniques daily and you will gain improvements!
Contributions
Thanks to Daniel Bales and Angela Wick for their valuable feedback.
Daniel Bales
www.sharpeyeanimation.com
Angela Wick
www.ba-squared.com
Resources
Definition of Ready – Jeff Sutherland
https://www.scruminc.com/definition-of-ready
Definition of Done – Jeff Sutherland
https://www.scruminc.com/definition-of-ready
The Three Cs
https://www.agilealliance.org/glossary/three-cs
Communicating the “What” instead of the “How” (Delivering intent)
“Greatness” by David Marquet https://youtu.be/OqmdLcyES_Q
Communicating Acceptance Criteria using Gherkin
https://docs.cucumber.io/gherkin/reference/
How to Invest in Your User Stories – Jeremy Jarrell
https://www.pivotaltracker.com/blog/how-to-invest-in-your-user-stories
About the author
Michael Nassif is a Principle at ZenAgile, a training and consulting firm that specializes in developing high performance, empowered organizations. They take a heart-centered approach by providing hands-on training and workshops in the applications of Lean and Agile.
