report-stories

From Scrum to Kanban – Why we did it

A case study of a battered Product Owner who has lost his crystal ball.

from  Jan Segers
25.02.2020

Scrum, Kanban, Scrumban - teams can choose their most suitable agile framework from a large number of different ones. But does the "right" framework even exist? When is it time to try something new? A field report of a battered product owner who has lost his crystal ball.

Spoiler Alert

To answer the question in advance: There is no framework that makes all teams equally happy. But of course there are frameworks that are sometimes better, sometimes worse, depending on the team setting. And don't worry, this is not going to be one of those random Scrum vs. Kanban articles. I'd rather talk out of the digital sewing box and give some food for thought.

Once upon a time ...

... a team as it is shown in the Scrum picture book: Product Owner, Scrum Master and six developers. This team was largely responsible for a very central and therefore business-critical service within REWE digital. In addition, the challenge was that this team was usually involved whenever a new feature was developed. As a result, I, as the product owner, was forced to make adjustments to almost every sprint because certain topics suddenly became more important at short notice than those planned beforehand - always in consultation with the team, of course. 

Even though the team understood our situation and the resulting constant scope changes, the collateral damage was immense. Sprint goals were mostly not achieved and stories had to be planned ad hoc. The zenith of our pain was reached after a retrospective study showed that within the last six months every (!) sprint had experienced a scope change.

Embrace the pain

The situation described above looks like a bad movie, but was our reality. Especially for me as a product owner, the setup was no longer sustainable, since the team could not produce any reliable velocity at all due to the constant torn sprints and I was therefore unable to make any statements about our delivery. After some discussions with other teams and Agile Coaches we decided to make a virtue of our necessity, eliminate sprints and optimize for flow.

Scrum + Kanban = Scrumban?

In retrospect we actually only made clear what we as a team had to do in our daily business anyway. We eliminated sprints because their scope had to be continuously adjusted. We introduced weekly refinements because we had to estimate new work in shorter cycles. We eliminated the two sprint plannings and replaced them with just-in-time plannings on story level after the daily. And last but not least we introduced a WIP limit, because we are doing Kanban now. ;-) Jokes aside, but the WIP limit forced us not to sit on more than just one chair at once, but only at the important ones. And not the ones you just hop onto because you can. This also applies in real life, by the way.

And now what about velocity?

The careful reader may have noticed that this report was written by a product owner. And what must a PO be able to do? Right, he or she must somehow be able to provide its stakeholders with the most realistic forecasting possible. In a nutshell: "When will it be ready?". With the elimination of sprints, velocity was also eliminated - after all, there was no longer a measurand. Instead, we measured the lead time for each story, ergo the number of days from the first line of code to rollout to production.

Forecasting - Level 1

In the first iteration stage, I had documented the number of days per story that we had managed. But that didn't really help me - although I was now able to tell our stakeholders how long it took to get a story into production, the statement was relatively vague. Some stories we had started and rolled out within a day, but some stories took more than three weeks. It's understandable that my initial answer to the question "When will the story be finished?" with "In one to twenty days" caused more irritation than happy faces ... 

Forecasting - Level 2

Back to square one. The only segmentation option available out of the box was the number of Story Points, which we still estimated in our refinements for each story. I am aware that one should avoid correlating complexity and time under any circumstances, but when I look at the data I collected last year, I think there is a clear correlation between the complexity of a story and its lead time.

Words are silver, data is gold: The light blue chart below represents the number of days we needed for each story with five story points and the light green chart represents the number of days we needed for each story with eight story points. Of course, there are outliers in both categories, up and down. Nevertheless, it's easy to see that a story with five Story Points is on average shorter than a story with eight Story Points. So there is a correlation between complexity and time, but no general statement can be derived from this.

What has the segmentation based on the Story Points achieved in our everyday life?

All-in-all, it helps to define the "from-to" corridor more closely. Let's take the above 5 Story Point example: There were some outliers to the very top, but most of the readings are within a corridor of two to ten days. Would I take all the measurements and communicate to my stakeholder that his 5 Story Point will take at least one and at most 22 days to roll out to production? Of course not, as it is obvious that these 22 days were an outlier. On top of that, the readings make it clear that it would be fatal simply to take the average and communicate it. Why? Well, in this example the average would probably be 5-6 days. If I would communicate this value to my stakeholder, I would be wrong in 80% of the cases. After all, in 80% of cases the measured values are not 5-6 days, but often enough above or below it. 

As a PO, it has therefore proven to be best for me to ignore the upper and lower 10% of the measured values and not include them in my statement. In this case this would mean that everything below three and above ten days would be ignored. I then communicate exactly this three to ten day range to the stakeholder. Of course, this is still not very precise and does not satisfy every stakeholder. But in fact, this statement is a reflection of reality.

If you measure, you measure crap.

Of course, there are many factors that influence these measurements (team strength, holidays, sick days, ...). In the end, I realized that the team prefers to work with small stories. These are better understood - and therefore have a much more constant lead time. Consistency is exactly what helps me as a PO especially in forecasting. In response to these measurements, I have therefore optimized my stories so that they are as small as possible - without losing sight of the respective business value. 

Looking back, the transition from Scrum to this form of Kanban was exactly what helped the team in their daily work. Sprints could no longer be torn because they simply no longer existed. Also ad-hoc re-prioritization of the backlog was no longer a problem. Can this methodology be seen as a blueprint for all team constellations? Certainly not, but it is always worth taking a look beyond the end of one's own nose!

 

Next Story from  Jan Segers

From Scrum to Kanban – Why we did it

Jan Segers
Next Story in : people-stories

Catrin Bluhm on good teamwork

Catrin Bluhm

Search here for Stories, Jobs and Categories…

Back
No search results for available
Robot
Unfortunatly your search term didn't generate any hits.
Further down we have several terms for you or take a look at our job openings!