What are ways that Agile teams can foster communication and collaboration of requirements between business and...
I think some business stakeholders wish that development teams could simply read their minds and know what they want! They’re busy and don’t want to spend more time in meetings. How can we get them engaged in giving development teams examples of desired and undesired system behavior which can be turned into executable specifications, the customer-facing acceptance tests that drive development?
One of my own team’s successful experiments was investing time for several iterations to sit down with people in each department of our company and learn how they do their jobs. This improved our understanding of their needs for new features, and also allows us to propose simpler, less expensive solutions to business problems.
Story mapping is an excellent way to engage stakeholders in planning a new theme or project. It’s a quick way for both the customer and development teams to visualize and prioritize areas that deliver the best return on investment. Stakeholders can “walk” the map, test their assumptions, and see each user story in the context of the big picture of the whole system. Ask your customers to try story mapping once. They’ll see how it helps them slice big blocks of requirements into small, valuable user stories, and plan their release.
Specification workshops are another proven way to involve managers in creating requirements without making them feel they’re wasting time in yet another meeting. Get the right people together and explain that this isn’t a planning or design session. Simply introduce a user story, and ask people to provide and discuss examples of how the delivered story should behave. Focus on what the business wants and why, not how it will be implemented from a development perspective. Specification workshops help the business and development teams create a shared language so they can communicate more throughout each theme or project.
One of the simplest ways to show business experts the value of communicating with technical experts is to demo the code written for each user story early and often. My team works on each user story incrementally, so we can get frequent feedback from stakeholders. For example, if we’re delivering a five-step wizard in the UI, we first create all five pages, linked with navigation links or buttons. We show this working software to the customer and ask her to try it out. It only takes a few minutes. Customers often don’t know what they really want until they actually use it.
When the general layout and navigation is agreeable, we start adding on small increments of functionality, getting customer input on each slice. The business people begin to trust that we won’t waste their time, and that they get value out of collaborating with us.
Dig Deeper on Software Requirements Gathering Techniques
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.