Agile Requirements by Collaboration

By Guest Blogger Rob Elbourn, Scrum Team Lead working at a major financial concern in UK. Visit Rob’s Agile78 Blog

I recently attended the “Agile Requirements by Collaboration” presentation at Skills Matter lead by Ellen Gottesdiener from EBG Consulting. Here are some of the main points I got from it.

Ellen described how collaboration needs to happen on several different levels of granularity along the way requirements are viewed on agile projects– the product (which establishes the product or portfolio roadmap), the release and the iteration (or work-in-progress).

Exploring these views can occur in several different facilitated workshops, from the roadmap workshop, to the release workshop to iteration workshops. The corresponding requirements that are clarified or driven out from these workshops also appear on different levels – boulder, rock and pebble.

The idea is that the pebbles form your user stories and are driven out at the level of the iteration workshop. Projects can encounter rock sized requirements at the iteration level and suffer a time delay as new pebble requirements are chipped off from them. This brings to question the level of “doneness” for a user story.

Tamp down those requirements!

As Ellen explained, agile planning involves a technique called rolling wave planning; this is a form of progressive requirements elaboration.

Why progressive requirements elaboration? Well – as Ellen pointed out, have you ever run a project where you knew all of the requirements from the start, and that they didn’t change? No? Well, this is where progressive requirements elaboration (and responding to change) helps.

Ellen went on to describe how to elicit value out of workshops by using the 6 P’s.

1. Purpose (why are we having this meeting – short an concise, resonates with all stakeholders)
2. Participants (key decision makers and involved people)
3. Principles (guidelines for participation owned by the group but led by the facilitator)
4. Products (outcomes of the workshop)
5. Place (where you are having the meeting)
6. Process (resulting in the agenda; one tip: how key stakeholder(s) kick-off the session and then return at the end with a show-and-tell summary)

A few of the other valuable one-liners I got from Ellen’s session included:

Requirements:

• Problem space overlaps solution space, so you need to iterate and spike!
• Tamping down requirements (or “doneness” of a user story (see picture above from Ellen’s presentation).
• The “cone of uncertainty” (see diagram below), can be reduced by breaking it down into smaller cones

Thinking

• Everyone on the team needs to think like a product owner and a tester
• Don’t be afraid of using both left and right brained processes to solve problems

Teamwork and Collaboration:

• A stable team is key (done a few iterations, everyone knows each other’s strengths)
• Workshops should contain the 6Ps (described above)
• Collaboration is the engine of team value!

The “Cone of Uncertainty” (first described by Software Engineering guru Barry Boehm) shows that our estimates at the start of a project are way off, but get better as development proceeds through time. As Ellen pointed out, in agile, we do many short development and delivery cycles over time, allowing us to improve our estimating each cycle and thereby decrease the delta between estimate and actual.

More resources:

• “Agile Requirements by Collaboration: Making Smart Choices about What and When to Build” by Ellen Gottesdiener
• “Amplifying Collaboration with Guerilla Facilitation” by Ellen Gottesdiener
• Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener
• Numerous article on Ellen’s company website in the categories of agile and facilitated workshops and requirements.
• Ellen’s blog