Several weeks ago my colleague Tamás made an interesting point about our planning meetings: we always committed to an iteration backlog - we are doing an interesting combination of Scrum and Kanban, but not Scrumban -, but we never asked our product owner whether she was happy with our commitment. She said that she hadn’t been satisfied, but followed what Scrum said anyway - classic autopilot behavior. This got me thinking and I realized that during the last couple of years every product owner I met had this very same problem: scrum was new and it didn’t help them much, because before Scrum the business dictated the speed of the development, but after introducing Scrum the development slowed down and started to live its own separate life.
In order to understand why, first have a look at this typical iteration backlog lifecycle:
The first sprint is usually more successful than the second one, but after five or six sprints the number of delivered user stories stabilizes - in Scrum terms: the velocity becomes stable. I talked to different Scrum Masters from different organisations and they independently told me that after the teams reach this kind of threshold, no matter what the product owner says or does, they deliver exactly the same amount of user stories. This is the point when the team starts its own life and starts to dictate to business: no matter what the product owner’s expectation is, she will get the same amount of user stories sprint by sprint. Which is somehow good, makes the development predictable, but the business is never predictable, on the contrary, it changes a lot. Since the outcome of the planning does not follow the expectations of the product owner - which is driven by the business - she starts to ignore Scrum and eventually she gives up and from then on she will just pretend to be a product owner, when in reality she will fall back to classic project management.
Following the book, I should somehow convince the product owner to think differently and keep up being a good product owner, but for a while now I haven’t tried to change people, because it is not possible in software business - there is simply no time for that. So, I rather change the inflexible Scrum methods and introduce something new called the expectation line:
The planning goes by the book of Scrum (we changed the planning as well, because it wasn’t effective for us, but that is a different story), but before the team makes the commitment, the product owner tells the team what commitment she’d be satisfied with. As you can see on the figure above, sometimes she wants more - sprint 8 -, but sometimes she just wants one single user story - sprint 9 -, and the team’s goal is to deliver according to the expectations of the product owner. This approach incites the team to follow the business needs and give up the convenient steady velocity. The diversity which comes from these changing expectations forces the team to speed up - sprint 11 - and find a way to deliver more if this is what the business needs at the moment. We are working like this for a while now and the feedbacks from the product owner and the team are good, and also this way we know more about the business needs than before.
For example, our last expectation line was so high that we needed two sprints to reach it. Actually, we failed to deliver in two weeks, but now we know where we screwed up and next time we’ll definitely finish a similar assignment in two weeks.
I found a flaw in the idea of having an expectation line: what if the product owner keeps the expectations always so high that it will burn out the team eventually? I think this will never happen with a reasonable product owner: she’ll know that “one cannot sprint through a marathon”. If she thinks differently, your project will fail anyway no matter what kind of new things you’ll introduce.
If you feel that your Scrum development is getting boring or you have an unmotivated product owner, try out the expectation line idea and let me know what happened.
comments powered by Disqus