There can be only one

The Product Owner (PO) is the sole owner of a product. The PO is responsible for maintaining and developing the product and do this the best way possible. The whole team helps the product owner in the hard day to day decision making, because the whole team cares about the product and its customers. The PO can be seen as the face of the product in an organisation.

Many companies implement the role of PO in a very different manner. Let's have a look at a few:

1. The senior product owner: A senior product owner could be someone with a lot of experience and is therefore a senior. But in this implementation that is not the case. The role of SPO is a hierarchical position above the PO, which means the PO is not solely responsible for the product anymore. As an effect, the PO will not feel responsible and will loose focus, decreasing team performance.
2. The product owner team: make multiple people PO and thus responsible for prioritisation of the backlog. There will never be consensus and the POs will be played against each other. This leads to reducing focus and therefore low performance.
3. The product owner support team: Take one PO, and put people with the PO in a separate team to do the refinement, estimation, slicing and prioritisation. The PO is suddenly in two teams and the team gathering information about the stories is not the team implementing the change, which will reduce effectiveness.
4. The product owner by proxy: in this scenario a PO is not dedicated to the team thus appointing someone else as a replacement. The latter will never have the responsibility of a real PO and can never make hard decisions. In this case the PO by proxy sometimes just doesn't know what to do and will therefor delay development and speed.

In my opinion these are all constructs to redirect ownership and avoid responsibility for the true role of the Product Owner and will always result in a lower performance. The PO is the funnel with the business. Everyone demanding something from a PO is called a stakeholder. Even in a hierarchical organisation where a PO has a manager, the manager is a stakeholder to the PO when it comes to requests for the product. See here a potential conflict. 

So when a PO is the absolute ruler of the product, how can we make sure the PO doesn't do anything stupid? Well, we trust in our PO. As mentioned the PO is backed by the team, the PO is interested in the wishes, demands and quirks of the stakeholders and needs to make tough decisions sometimes in prioritising. And the PO, just like anyone else, makes mistakes. But mistakes cannot be prevented, just like a taxi driver will have a dent so now and then. We cannot prevent mistakes, but we can help the PO in making the damage as small as possible by creating a save environment where the PO has trust from everyone, autonomy to make the right decisions and authority on the product developed.

The power of Scrum is in it's simplicity. Make everything small and simple. The responsibility of the PO is also small and simple; there can be only one. 

If you have any PO constructs, please share in the comments.

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.

Planning in Scrum: story points and planning poker (2/2)

This is the second article about Planning in Scrum

Scrum

What does Scrum teaches us about planning? To be precise, nothing. The only thing Scrum demands is that you plan. There is a timebox in Scrum that dictates that you plan, the timebox is about 5% of the sprints hours. So for a sprint of a month, you should take a day to plan, for a sprint of a week you should take two hours. 

In this timebox, there are three activities. At first the value of the sprint is determined. What value will be added this sprint, what will be our sprint goal? Then the work that needs to be done to achieve that  goal is gathered. The last activity is to determine how the work is done. 

To be honest, I rarely experience teams that do all three. But one of the most important things here is that in Scrum it is mandatory that you plan.

Story Points

So what about those Story Points (SP) then? Hate to tell you, Story Points are not a part of the Scrum framework. But, what are they? Story Points are numbers we give to work items to indicate complexity. Complexity is more then just time, it is also about how difficult it is to achieve the outcome. A small simple task may be one SP and a large complex one 100 SP. What about a small complex one? And a large simple one? Those are somewhere in between.

Story Points can be compared to travel distance. If you travel from Paris to Berlin by car you need to drive about 1058 km. This distance won't change, it will always be around 1000 km. We can say the distance between Paris and Berlin is 1000 SP. And how long will we need to drive by car to get from Paris to Berlin? It depends. If we don't take a break and drive a steady 100 kph we will reach our destination in about 10 hours. We will not account for traffics jams, fog, detours etc. In this case 1000 SP will take us 10 hours to complete. But if we put in the variance of the troubles on route it is safe to say that we will reach our destination in 11 hours plus or minus an hour. In this case 1000 SP is comparable to 10-12 hours. 

Therefor we can use SP in planning to talk about effort of work, but we won't be sure when the work completes.

Empirical

Planning in Scrum with Story Points is an empirical process. We need to learn that we, as a team, understand the size of SPs. Before we start planning we can build a reference board with work items we consider one SP and work items that are of another order. We can use this board for all future planning. The more we plan, the better we get at planning, the better we will understand what it means to have a work item of one SP and a work item of 30 SP. 

The better we get in planning, the better we get in becoming predictable. Stakeholders love it when we are predictable and they hate it to be surprised (but when you surprise them, better make sure it's a good surprise). Predictability can be measured in estimated SP / achieved SP * 100%. The closer to the 100% the more predictable a team is, the better they understand the work that needs to be done, and the better their performance.

Planning Poker

We can also use the reference board to derive a game of: Planning Poker. With Planning Poker we keep the reference stories in our head (or we take a glimpse on the board) and we guestimate how many SP a story is. Planning Poker is not a part of the Scrum framework, it is just used a lot to facilitate planning. The cards are most of the time based on a numbered sequence based on the Fibonacci sequence. This sequence starts with a zero and a one and the next number is the sum of the last two: 0 1 1 2 3 5 8 etc. Some card sets use the exact numbers, some a simplified set.

In most Planning Poker sets there is a 0, a coffee and a question mark. Get rid of those. There is no work that is worth 0 SP; it would mean the work is already done and shouldn't even be considered to be taken up in a Sprint. The coffee is for indication of a break; still communication in a group can be done with our mouths and it works much better. The same goes for the questions mark; if you have a question, just ask.

With Planning Poker cards are played in two rounds and team members guess how many SP a work item is. Science has proven that the bigger the group, the better the estimate. Therefor everybody needs to estimate, even if they think they don't know how to solve the story. Anyone who abstains won't learn to improve in planning or ask the right questions.

Planning Poker is not about poker, it is about planning and understanding what needs to be done to achieve the Sprint goal. It cannot be played wrong, as long as there is feedback making sure we can learn from each other.

Conclusion

Planning is an empirical process and hard to master. Planning is easier with references. Planning in Scrum is mandatory, figure out the best way how to do it with your team. And if you decide to work with Story Points and planning poker, take the time to understand what you are doing.

Planning in Scrum: planning and variance (1/2)

This article is one of two about Planning in Scrum

We humans really suck at planning. We can plan simple things pretty accurate: cleaning the house, food preparation, repetitive labor. Planning improves if we do the same or similar tasks often. We learn it by doing. But for the rest? Planning of anything that isn't simple is hard.

One of the things that surprises me is that we don't get taught planning in school. In high school teachers assume the students can plan, but it has never been taught in primary school. And it doesn't improve after high school either. There is a general assumption that everybody can plan, although we all know we can't.

Planning

Planning is about three things, the first one is time, the second one is breakdown and the third one is order. When we talk about time we want to know how much time we need to complete the work. We can guestimate that vacuuming the living room will take approximately half an hour. But we also know that there can be a slight variance in time. Which means that all time estimations should carry a variance with them. We should say: "vacuuming the living room will take me half an hour plus or minus five minutes or between 25 and 35 minutes". 

For bigger tasks we need to break them down in smaller task we can comprehend and plan. So if there is the task of vacuuming the entire house, we should break it up in vacuuming per room. Smaller tasks are easier to understand and guestimate. 

Last but not least we need to take into account that there is an order in doing things. Vacuuming the attic, then the basement and then the living room doesn't sounds like a practical order. We must reorder to optimize our work plan. All in all planning is more then just a time estimate and even that is worthless without knowing the variance.

Variance

Variance is the deviation from the norm. So if we plan an hour and it can be either five minutes shorter or longer, the variance is five minutes. All estimation should have a variance to predict minimum and maximum time needed. The time we need is only known in hindsight, but should be somewhere between min and max. The larger the estimation, the larger the variance. The ratio between estimation and variance is not linear. It is more exponential. This means that the bigger the job, the bigger the variance can be. And the variance will grow more compared to the increase in time. Which enforces the need to breakdown work.

Conclusion

Planning is hard to master, it takes three ingredients: time, breakdown and order. And when talking about time, always mention the variance.

Next week we talk about story points and planning poker

Refinement in Scrum

"Refining breaks crude oil down into its various components, which are then selectively reconfigured into new products." - CEEF

Crude oil is refined into various, better and more defined products. Each end product is of better quality than the crude oil was. Refinement in Scrum is no different. Stories are scrutinized, broken down and up, sliced, inspected and adapted until there is a better quality story. But how does refinement work in Scrum and who should be there?

"Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs." - 2020 Scrum guide

It is not clear, by the 2020 Scrum guide, who is responsible and it is not clear who will attend. Since the product owner is responsible for the backlog he/she makes a good candidate to be responsible for the quality of its contents. The developers must use the product backlog items to work with; unclear stories might slow them down. For their own sake, developers are pretty good candidates as well. If we look at who will attend a refinement the best answer would be: those that are needed to make the story understandable. Most of the time this will be the developers or a subset and most of the time with the product owner. Sometimes we might need more developers and sometimes we should even invite the reporter or stakeholder to clarify.

According to the Scrum guide, the refinement (which is mentioned only once) is an ongoing process. And in the old guide (2017) about 10% of the time is reserved for refinement. This is up to four hours a week. This sounds like a lot of time, however in waterfall environments this time has already been spent in the planning before coding even started. Refinement is about understanding what needs to be done and that needs to be done often. My advice is to do refinement each day for an hour, just pick the top stories from the backlog and improve their quality. But don't over do it, refine only a bit more than what the team thinks can fit in a sprint.


To make refinement easier, it's common practice to agree on the quality of the work item in a definitoin of ready. Keep in mind that, just like the definition of done, it is not the purpose of the DoR to be an equivalent of a checklist. But a list of quality requirements.

And one last important aspect of refinement is for the members of the refinement: come prepared. Take some time before refinement to read the work items that are going to be refined, formulate questions or even collect some information up front. In the end it is always about delivering the right product increment the customer asks for (which is always more important than following procedure)

Daily Scrum

The Daily Scrum or Stand-up is a meeting to improve collaboration towards the Sprint goal. In the Daily Scrum we should make a plan for the next 24 hours to get work done which contributes towards the Sprint Goal. In the Daily Scrum we explain to each other which impediments we encountered during the last 24 hours and we discuss how we can resolve those. 

What we shouldn't do is to sum up a list of things we've done. That should have been made clear on the Scrum Board. Scrum is about transparency and the state of our work should always be visible. In the Daily Scrum we ask ourselves what we should do to move closer to the Sprint Goal, we don't discuss all the meetings we are going to today. This Daily event is time boxed at fifteen minutes; those fifteen minutes are all we get to align ourselves in moving towards the Sprint Goal.

The Daily Scrum is held by and for the Development Team (not the Scrum Team). Everybody is allowed to listen and only members of the Development Team are allowed to speak; even if you are a very important manager of some sort, simply hold it. As a Development Team we inspect what we did and what we should do to complete the work we committed to. When there are impediments we should make a plan to resolve those in order to finish the work. When it is clear that work won't get done in the allotted time frame we are obliged to inform the stakeholders to prevent surprises. The Daily Scrum is a tool to prevent (un)happy surprises. When we perform the Daily Scrum well, we encounter problems, but those should not age beyond a day. 

Performing a Daily Scrum well is hard. It will turn into a status meeting if we don't pay attention to the purpose of the Daily Scrum. So here are some tips:

1. Always meet at the same place and at the same time
2. Monitor time
3. Be there
4. Use your Scrum Master to improve the Daily Scrum
5. Don't let the Scrum Master take control of the Daily Scrum
6. Inspect work done
7. Inspect impediments
8. Focus on getting things done
9. Think about WIP-limits: a maximum of jobs that can be in progress
10. Work together, don't sit on your own island of work
11. After the Daily Scrum inform Stakeholders to prevent surprises
    

Scrum, Empiricism and the Scientific Method

The first thing most of us learn is that Scrum is an empirical method. And the first thing we forget about Scrum is that Scrum is an empirical method. What the heck is an empirical method anyway? Let’s find out. An empirical approach is a philosophical approach in science. It is known as the scientific method and is used to find answers when direct experimentation is not possible. The scientific method is an iterative approach. Ask a question, formulate an hypothesis, experiment and analyse. Rinse and repeat when necessary. A part of the scientific method is seen in Scrum when looking at the three pillars: inspection, adaption and transparency. But this is only the last part of the scientific method. The first part is putting up an hypothesis based on a question. So instead of using the User Story technique we will use the Scientific Method to formulate our change request. A User Story is nice to get the features anyone wants on the table, but it lacks the opportunity to fully measure the effects of the feature. The scientific approach would be to formulate a User Story as an hypothesis as an answer to a question. And because the hypothesis needs to be tested and validated, a part of the story would also be defining the sensors or metrics on which to base success or failure. An hypothesis is an educated guess as an answer to a question. Q: “When [we change this] what would happen?” H: “If [we change this] we think [this will happen] which we prove [with this metric]” For example: “If we add a shuffle method to our music player, people will use our player more often which we measure with the increased use of our player in the next three months”. We now have a feature defined in the scientific method with an hypothesis. We also defined the metric to prove or disprove that our change has the desired effect. An hypothesis is true as long as it isn’t proven wrong. So besides proving that the increase in orders in the above example was caused by the new feature, we might as well test if this wasn’t the case. What other factors did contribute? Was the feature solely responsible for the increase in use? Did the usage actually increase? What do we need to investigate next? An hypothesis therefore always has a question and there are always multiple ways to investigate the question with different hypotheses. So the scientific method is about defining the right metrics to prove that a certain feature is making a difference for the customer. Business wise the scientific method would show the hypothesis and the direct benefit of a change. When a metric of the scientific method is defined, there should be a threshold that defines the success of the case, e.a. make it SMART. Using the scientific method will open up the ways we do DevOps, we should be able to integrate even more with the business, with less hassle on feature requests and more prove that what we do actually matters. Sources: https://en.wikipedia.org/wiki/Empiricism https://www.sciencebuddies.org/blog/a-strong-hypothesis https://www.sciencebuddies.org/science-fair-projects/science-fair/steps-of-the-scientific-method?from=Blog