Don’t have a strong product owner?

In this post we explore why a product owner is needed, and how we can ease the burden on the customer as well as the product owner by setting expectations and speaking in language the customer understands.

Recently received this email from a fantastic gentleman who runs an Engineering team in a wonderful part of the world (let’s call him Bob). Bob is facing some challenges with the business side of the company who is his customer:

  1. Business wants hard deadlines for completed functionality. However they do not provide clean and concise scope / acceptance criteria. Further, they struggle with the concept of iterating to a solution and just want it now.
  2. Lack of understanding from the business about the level of effort required to be a successful Product Owner. The business is the customer and the customer can not articulate their vision (perhaps they believe we should read their minds).
  3. The business can not focus, going from one thing to the next before Engineering has had a chance to complete the first item.

It’s great to get emails like this as it just reminds me we’re all struggling with many of the same challenges. For instance, I’m having a similar conversation with another fine gentleman (Steve) in another part of the world, at another company. The key difference is that Steve is on the other side of the equation. Steve is the business side that is struggling with an Engineering team which can not deliver.

I wanted to share the two sides, as told from different people at different companies, as they are useful in helping us overcome these shared challenges.

So, Steve is on the business side and can’t understand why the Engineering team just doesn’t deliver what he wants, when he wants it.

Steve and I walked through an exercise where I asked him for all of the requirements he wanted in his “2.0” release. He rattled off several things, and then started out on some more. I asked him why they were important, what he was trying to solve with each.

All the while his Engineering team is struggling – they hear “go this way”, “no, go that way” and never feel like they have clear direction or a vision. So, I continue with the gentleman (who should be wearing a PO hat, although is a business owner so “doesn’t have the time”) and ask him to order the top three things he wants, out of that long list of ideas. Steve does so.

I want to confirm with him – “are you sure these are key to 2.0?”, I ask. Steve says that yes, that is what he wants for 2.0. I explain that he hasn’t mentioned the UI/UX rewrite the team is currently working on, nor has he mentioned X, Y, Z from the teams backlog. “So why are they working on all this stuff which is nice to have and not valuable?” I ask.

Steve hasn’t noticed that he is pushing the team in a different direction every day. He hasn’t noticed that the vision has not been set, or communicated.

In that situation, and I’m sure this is similar to Bob’s, there is a lot going on. The business folks have a million things they want, but there is only one thing top of mind at the time you speak with them. So it looks like they have no vision. I asked Steve to write the release blog for his 2.0 – what would he like it to say, how would he pitch it to his clients, etc.

This was a forcing function to get Steve to consider the scope for his 2.0. It was a release planning exercise in language he understood – a blog post, not a backlog.

Now I’m not sure how successful this approach will be at every company, for every team. I do hope that it provides the business side an understanding of what is involved in being a product owner and setting a vision. Of course you can also use this as a tool to define scope for a release – if/when the business comes back to Engineering and adds something to the list you can respond with “didn’t we agree last Tuesday to do X, Y, Z first, and then move on to other items?”. Don’t let agile be an excuse for less discipline, more WIP, and less value being delivered.

Be agile. Be smart. Help the business side, or your customer, have some discipline and get value early and often. We need to educate our customers as much as we need to educate ourselves.

Got thoughts or suggestions for Bob or Steve? Share them in the comments below.

Why do high performing Scrum teams use story point estimation?

There are two common approaches to estimation in Scrum teams: story points and ideal hours. Ideal hours is taken as ‘given what we know today, how long would this story take to implement?’ if everything went according to plan.

It turns out that us humans are pretty terrible at estimating. For example, is this story, with this acceptance criteria, going to take three or four hours? If you’re familiar with this situation you’ll agree it can be hard to tell.

As the team wants to give the client a pretty accurate idea of when they will deliver the story they ask for more information upfront and we find ourselves in the situation where we are defining everything upfront to get a slightly more accurate estimate. This is waterfall people, not what we want!

Estimate = Guess

If we remember one key thing, it is this: an estimate is a guess. That’s it people, an estimate is a guess, it is not a commitment, it is not a firm delivery date. The more time we spend talking about a story to clarify it the closer we’ll be to an estimate in hours that reflects the required number of hours to implement that story. Unfortunately we won’t be any closer to actually delivering it!

Given humans are bad a estimating we can use a relative approach to estimation. For example, what is heavier, 7000 elephants or 1 jumbo jet?

Enter Fibonacci

The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’. This is a similar problem to the ideal hours described above.

Further to that, reaching consensus on a story point estimate, and getting clarity on acceptance criteria is made easier with the help of planning poker. With planning poker we hand out a set of cards with the fibonacci sequence (1, 2, 3, 5, 8, 13, 21) on them to each member of the team. As the team reads out a story and the acceptance criteria each team member picks a card from their deck and leaves it face down on the table. Once everyone has selected a card the whole team turns over their cards and compares the estimates.

This has two benefits, it is a quick way to estimate and the team has a fruitful discussion about the story and acceptance criteria.

Finally, when a team uses story points for estimation there is no confusion with the customer as to this being a commitment – what would committing to ‘5 story points’ actually mean? As there are no ideal hours attached the customer is under no illusion as to the time involved. Thus freeing the team from an artificial deadline.

Want to learn more about high performing Scrum teams? Sign up now to be notified of the next blog post or podcast.