Learn to say "No" and become predictable

People in general don't like surprises. When they are being surprised there is a very basic human emotion: "fight or flight" and a shot of adrenaline. When it turns out the surprise is for the better we can enjoy the adrenaline. But when it is a bad surprise we get angry or sad. So if you want to surprise somebody, make sure it's a good surprise.  

As a Scrum team we have the ability to surprise once in a while at the Sprint Review. But stakeholders don't like surprises anymore then anyone else. So we should try to be predictable as a team and minimize surprise.

A Scrum team typically calculates the amount of work they can do in a Sprint. They use Story Points, T-shirt sizes or even apples to make predictions and to achieve the Sprint Goal. At the Sprint Review all the work that has been done is officially revealed. And if the team did well they deliver what was predicted. A lot of times teams are measured by the work they have done in an absolute measurement, like counting total amount of Story Points delivered.

And as Peter Drucker stated, when we measure something we improve on it. So if we measure Story Point, they will increase. This makes me wonder: "Does the amount of work done increases as well?"

The answer is most probably: "perhaps". So how can we improve this measurement? Well it seems that our stakeholders are interested in the work done and they don't like surprises. So let's improve on the measurement, let's measure predictability. When we have calculated the total amount of Story Points done we should divide the predicted amount of Story Points by it and multiply with 100. This number tells us if we surprised our stakeholders and is a measurement about how good we are able to plan in percentages.

Predictability = Estimated SP / Delivered SP * 100

When we now how predictable we are we can try to improve. Improvement on predictability can be done in a couple of ways and we will focus on one for now.

You can improve on predictability by making better promises. Better promises are made by getting more focus. Focus is gained by saying "No" to everything that is not part of the current focus. A ballpark estimate is that a good Product Owner will say no to up to 80% of the change requests. The PO always has two options when a new request is made: yes (20%) or no (80%). Of the 80% no's at least half will not even show up on the backlog and end in the bin.

We need to make choices to increase our performance. This means that we need to have the courage to say "No" in order to be able to focus, perform and deliver on the things we say "Yes" to. In Scrum there is only one person responsible for changes that are made to the product and that is the Product Owner and the Product Owner alone. There is no committee overseeing PO's, there can be no manager pushing changes to the Product Owner (he can make request of course just as any other stakeholder). A Product Owner is solely responsible for the product. As a team we should help the Product Owner in making these hard decisions and stand the Product Owner.

In summary we need to say "No" more often to increase focus on the goals we want to achieve. Resulting in more predictability and happier stakeholders.