Skip to content

Scrum Master Tip #2 : Ready? Set, GO

October 19, 2011

It’s a frequent thing for teams to say some things weren’t delivered because Product backlog Items weren’t properly defined. “The PO doesn’t know what he wants”.

It doesn’t mean that this is always true :) specially if the team is still in a Blaming stage. But it happens.

If you work in a big company, full of hierarchies and departments you know what I’m talking about – rarely the Product owner (PO) is the customer or a customer representative.
Sadly, the PO is some guy in a Product Management area with more than 5 guys between him and the real customer. I’m not saying this is wrong or right, just writing about a fact – in big companies, aka companies with lots of levels, there is no understanding from everyone working on the product about customer real needs.

So, imagine this “PO” defining some Product Backlog Items (PBI) for the “customer”.. yes, it will not be good.
Let’s help him! Simple things as defining readiness criteria (Definition of Ready) can help on getting things less unstable and unknown.. or at least less What-the-hell-is-this?

Before picking up a User story or feature to work on, Scrum team ( PO +Dev team+ Scrum master) should look at the product backlog and do the following exercise to check is the PBI is ready to be part of a sprint:

OUR Product Backlog Item  is ready when it has answered to three questions:
Why?
What are the stakeholders trying to achieve? What are their goals? What is the business context? What is the Quantified Value?
What?
What is the Outcome Vision? What is the end result of the user story?
How?
What is the Implementation Strategy? What is the associated cost (story points)? Is the story small enough (story points vs. team velocity)? And it has been estimated and it is small enough (to fit in a sprint)?

If the PBI is not READY, then there’s one thing you should do:  if that PBI  is a priority, mark it to be groomed during next Sprint.
During grooming assess PBI value, objective, size (break it in smaller manageable units – preferably get them to have a size less than  half the team velocity) and then, do something for you, your team, your product, your company … specify with examples.

Have a nice day :)

Advertisements

From → Agile, People, Scrum, Tips

Leave a Comment

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: