Requirements uncertainty is desired!

I tend to instill the Lean mind-set into the act or may be art of Agile requirements management. User story workshop which we conduct shortly after developing the product vision can be very useful, because:

  • It creates the forum for interactions among product owner, client, development team (developers, testers, UX), architects and other relevant stakeholders.
  • It sets the scene for emerging requirements.
  • It provides very quickly Inspection point to the product owner on the requirements.
  • It levels the understanding across development team, product owner and client.
  • The most important benefit from my view is to allow product owner to change her mind and to send the message that requirements are here to change and  to emerge different ones.

For me this has been a shift in my mind-set because historically we used to create Product Requirements Document before starting the development. It’s a shift from the big requirements up-front mentality where the development team was introduced to the requirements after being baked. Change of already baked requirements was expensive and took long time, despite of being early in the project.

Base-lining of requirements beyond one or two sprints, for me, can be a smell for:

  • Lack of interactions and involvements of developers and client in requirements definition.
  • Insufficient change rate in the product backlog which reflects possible failure to include clients valued items. This can indicate lack of the product ability to cope with the dynamic market changes.

Though the product owner job is to ensure high valued stories are in a state ready for the sprint planning meeting, more important is to ensure adequate process has been used for creating them.

For me the adequate process is Just-in-time thinking in developing the requirements. As follows:

  • Articulate and communicate product vision.
  • Hold user stories workshop shortly after the product vision in place.
  • Hold one sizing meeting up-front.
  • Hold product backlog sizing and Grooming meeting in every sprint.
  • Start the first sprint very shortly after the user stories workshop and keep grooming the product backlog based on the feedback from sprint retrospective.

The product owner role can be very demanding in terms of communication, coping with change in business domain and assuming required leadership on acceptance of the product. For me the ability to start based on vague requirements but directly after the user story workshop is critical to having Agile.

Related resources

  1. Product owner as Gate Keeper
  2. User stories applied for Agile software development
  3. Agile product management with Scrum
  4. Implementing Lean software development from concept to cash

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s