Accept Software Resource Library

Right Requirements in an Agile World

What are the RIGHT requirements? It used to be you planned a release and listed the must-haves and got them... Eventually

But with agile we get the product backlog faster... Yeah? i.e are those the Right requirements?

Who owns the definition of the right requirements?

Of course, the words "right" and "own" are ambiguous and even within a specific company culture where they might have a specific meaning; they are oft clouded by perception, interpersonal dynamics, political clout, etc. Any stakeholder will likely have a different definition on the right requirements.

One thing agile does well is to formalize a role called the Product Owner, someone who represents the customer to the sprint (iteration) team. The Product Owner participates in the Sprint Planning session and answers clarification questions about the stories and other items in the Product Backlog.

Assuming the Product Owner is singular then there is at least one person to blame when the requirements are not "Right", i.e. if the product fails, you should start asking the product owner what went wrong.

In my consulting work, I've noticed a interesting trend in multi-product manager organizations that embrace agile. They designate a "Lead PM" as the Product Owner, and to rotate that the Lead PM designation at regular intervals. That allows the reality of having the Product Owner (one person) participate in the daily stand-up and other sprint meetings (It does not scale well to have many product managers attending those meetings.) Instead they spread the hot seat and responsibility when you have a large organization to make the agile Product Owner concept work.

Now how does the Product Owner pick the right requirements?

More on that next week...