Agile Requirements Process

The following is a proposal I made to one client.  Might be useful for you.

REQUIREMENTS DISCUSSION

We propose a 1-hour discussion of the following practical suggestions.

NEEDS

(I am guessing; these are common.)

• we need an agile, adaptive solution
• part of the adaptation is to the specific people and situation of each Team
• we need something they can learn quickly and improve over time
• we need something that each Team will own, and will want to make work
• we need to increase the sense of responsibility and reduce the blame game
• we need better requirements but produced at a lower cost or at least a fairly low cost
• we need an MVP delivered faster (and better requirements are central to that)

SUGGESTION:

Let’s discuss the DOR (Definition of Ready) concept and how your team(s) might use it.

This is an approach that Jeff Sutherland recommends.

BASIC IDEA

The Team already has or can quickly develop a full Product Backlog of stories.

These stories provide, at a middle level of abstraction, “all” the requirements we know of so far.  The Product Backlog gives “the big picture” for the Doers (coders and testers).  It is also expected to change, for many reasons.

The Team defines a first draft DOR.  Defines what kinds of details are wanted (and can be supplied) for our kinds of stories.  (We have multiple kinds of stories.)

This DOR discussion includes any suggestions about format, types of information, templates, pictures, lists, etc, etc.  These must be workable for these people.  Or they can be things or techniques that will be learned over time.  These can vary a lot depending on the work, the organization, and the specific people.

Examples: Acceptance criteria, Use case, process flow, business flow, mock-up, wireframes,  business rules, data elements, SME, small size, SPs ok, INVEST, data flow, system flow, API details, Interface details, lists, Questions answered, Tech Issues, Dependencies, Why?, BVPs ok, test scenarios, etc.  (Probably redundancy in this list; possibly useful.)

We identify the [8] stories for the Sprint that is 2 sprints ahead (we’ll call this Sprint 5).  PO and Doers discuss specific needs per story.

The PO works with “the Minions” (the right people with the details for those stories) for 2 Sprints to develop “all” the details.  The kinds of details that the Doers have said they need.  And have said specifically for these stories.

Just before Sprint 5, the Team meets to review the stories and the details that are available.  The Doers vote.  

(a) Details and that story accepted as “all we need”

(b) Details (and story) almost complete except for 1 question

(c) Story rejected, not enough information

For whatever stories are rejected, the PO has another story as a substitute that is ready.

During the Sprint, the Doers will still have some questions about the requirements.  Hopefully not so many questions. Hopefully, the PO gets the questions answered quickly.

During the Sprint Review, we see how well the communication worked.  Inevitably, not perfectly.

In the Sprint Review (if short) or the Retrospective or another place, we discuss how to tweak the “DOR process” so that the requirements or details are better next time.  We live and learn.

FINAL COMMENT

That was a fast run-through of Jeff Sutherland’s idea.  Certainly too fast.  

Let’s discuss it and whether it might be something to try with your teams.

***

Comments welcome in two areas (at least):

• Using these ideas and selling them to the right people
• The strengths and weaknesses (at least perceived) in the specific suggestions

« « Postponing the Sprint Start? || An Agile Approach to Requirements » »