A few months back I discovered a blog post discussing the use of a Ready Board.  The author, Serge Beaumont, lays out a well described argument for the importance of a Ready Board.

We do a great job in Agile focusing in on the function of the team.  We write and learn in certification courses about not taking on a story in a Sprint until it is ready, not allowing changes to the story when in a Sprint and we define when a story should be considered done (complete).  The absence of discussion about the process a Product Owner and in many cases a Business Analyst does to prepare a story is troubling.  That process should be as clearly defined as the Sprint to Release cycle.  Serge Beaumont does a good job touching on this as he talks about the Ready Board.

While the author, Serge, says that Agile has two stable ’states’, I’ll refer to them two stable ‘history’ moments.  A story being “Ready” and a story being “Done”.  Those two moments in the history of the story are indeed the only times they are stable.

To illustrate here are three images from Serge’s blog:

The image above represents the two ‘history’ moments in the life cycle of a Agile story.  Most of our focus in Agile is between the Ready state and the Done state.  That is when a story is committed to by the team for a Sprint, worked on, tested, and delivered as Done.  Remember that Agile encourages, even demands, a story be “Potentially Shippable” when it is “Done”.

The above illustration of where the PO focuses and where the Team focuses is a great one.  Keep this one in mind as you look at the following illustration.  This is where your focus as Product Owner (and in many cases a Business Analyst) should be.  If you are fortunate to have a Business Analyst on your team, they would be focused along with you on getting “New” stories and moving them towards this “Ready” state.

The question of how to know if your stories are “Ready” or not is a good one.  The key is to work with your development team(s) to help define “Ready”.  They will help answer questions about; A) When is a story at level small enough for 1 iteration and B) When does it have just enough detail (along with Acceptance Criteria, etc) for the development team to feel comfortable starting their work?  This conversation should be collaborative with the team and adjustable over time as the process is improved.  As you work closely with your team(s) you’ll be able to set the standards for your User Stories and you’ll learn fairly quickly how to know your stories are “Ready”.

Before I had the “Ready” board concept in mind it was easier getting focused in on the details and spreading time to thin between new stories coming in all the way through to a story being done.  It is easy to get lost given the below.

A Product Owners (and again in many cases a Business Analyst’s) responsibilities are varied and cover areas such as;

• Requirements gathering
• Developing user stories
• Communicating frequently with the business or client
• Analyzing importance and setting priority of user stories
• Being available to team in answering questions and providing clarification
• Planning for upcoming Sprints
• Planning for several future Sprints
• Negotiating with business or client and team
• Supporting team in their Sprint commitment
• Being familiar with technologies used by team
• Evaluating velocity and searching for new a better ways for team improve
• Being engaged and familiar with daily team issues
• Staying three steps ahead in all areas

One of the biggest challenges we face is staying far enough back that you see the forest instead of the trees when looking at the above list (there are 13 items summarized above).  Stepping back far enough is critical to performing your core function as a Product Owner.

The Ready board is a perfect aide in ensuring you are able to stay far enough back from the detail of your project.  In the life cycle of a story making its way from creation through to production and used by the end user, your Ready board is one of the best tools for you as a Product Owner.

Enjoy and please comment.