An Agile Approach to Requirements

Below is the first draft on this topic.  With a big need to be shorter.  I eventually wrote something shorter.

***

An Agile Approach

We propose that we discuss this for an hour.

INTRODUCTORY THOUGHTS

When we start working on a product, there are many unknowns, often including:

• What is the real problem?
• What is the best solution?
• What does the product need to be, in some detail?
• Can we (the Team) build this within the constraints?

Rather than being “caught” waiting for perfect information to arrive, we in Agile recommend learning by doing.  Take action, see if you can do something, and then learn from that.  And typically, with a little luck, taking action quickly, and learning in the real world, we can make out way towards success.

The question becomes: what is the most effective way for adults to learn.  Especially for this Team.

THE REQUIREMENTS ISSUE

Let us mention a few keys ideas now.

Agile means that we no longer believe it is possible or useful to define all the requirements upfront.  For many reasons.

BUT: We can quickly define all the “stories” we know so far.  So that we have a fairly full Product Backlog.  And, at a middle level of abstraction, these stories represent the requirements.

AND: We can try to assure, sprint by sprint, that the Doers (the coders and testers in a Scrum team) have “all” the information they say they need to build the stories successfully.

This problem led Jeff Sutherland to define the Definition of Ready concept, which is very similar to the Definition of Done concept.

The Team has a meeting before each Sprint Planning Meeting to review all the “documentation” we have so far on the stories expected for the next Sprint.  Let’s say it is 8 stories.  And the Doers can vote on the details of each of those 8 stories.  Are they good enough. And reject stories.

The PO is responsible for pulling together all the details (as lists, pictures, whatever), using whatever people are available on the “business side”.  Including addressing some technical issues.

Just enough.  What the Doers need to know, but do not know yet.   Nothing extra (we do NOT document (again) what they already know).

So, what details are needed?

What exactly is needed is typically not well known at first.

But the PO and the Doers can start doing this.  And thus start to see what works and what does not.

And learn.

And start to more accurately provide what is needed.  Given these specific people and this situation.

So that they can be successful in building the stories. And become more successful.

NOT:

• everything the Doers might need
• what the PO (or someone else) wants to give them
• what one person wants

BUT IT IS:

• what the Team needs
• a reasonable compromise between what is needed and what can be delivered
• a “flow” way of delivering “requirements” based on continuous learning and feedback
• adaptive to the changing needs of different kinds of work (different types of stories)
• what is reasonable
• assuming improving communication and collaboration in the Team (including collaboration during the Sprint between the PO and the Doers)

IT CAN BE:

• based on prior thoughts, techniques, documents or templates that these people have used before, or want to try
• involve a wide variety of people, depending on where the knowledge is for each story in your specific organization
• you might use, possibly: BAs, SBAs, SMEs, smart people, Managers, Supervisors, people who do the real work, etc.
• we recommend pictures with discussion (Q&A)

WHO IS RESPONSIBLE

• the Doers are responsible for explaining what information they need and do not need
• the Doers are responsible for using the information given to build a great product more quickly
• the PO is responsible for pulling together most of the information (the PO must be supported by others, if you have, eg, 5 Doers)
• the PO must help change the organization (specific people) so that it (they) can develop a simple flow model for doing this
• Everyone is responsible for seeing how the communication is successful or NOT, and helping adjust things towards greater success
• the PO and the SM must advocate for and explain mainly three things:
• both good and bad change will happen – hence we must be agile
• in multiple ways, we learn by doing
• “garbage in – garbage out” – we must set up the Doers for success

NOTE

We are talking here about discovering the “requirements”, but also important are discovering the high-value stuff and raising the motivation of the Team.

« « Agile Requirements Process || More, Better… » »