Improving Product Value Delivery
visual experiment inside Scrum teams
I would like to share an experiment I have done inside a Scrum team to improve the product value delivered and the team’s awareness in respect of 2 Agile principles (“Deliver frequently” & “Deliver value early”).
Some context
As an Agile Coach, I’m working with two teams who are oriented towards very technical projects, often with big tasks.
In our retros I have seen a common theme: On one hand our developers are frustrated from not seeing the results of their hard work, and the other hand Product people can’t easily see the value to be expected from those tasks. So here’s what I tried!
The experiment
I started using a graph in our retros where the whole team (Devs & Product) could express their feelings about the product value delivered during the sprint.
Before a team member explained their post-its/ideas during the retro routine, I asked them to add a dot on a drawn “value delivered scale” (jewel ring / beautiful gift / happy shit ). After adding the dot everyone had to explain briefly why they perceived that level of product value delivered, and we moved onto the regular retro routine.
*Note :
90% of developers asks about X-axis, you can say it’s like an histogram with one dot for every sample or do like i did “it’s just there to avoid that Y-axis collapse”
Results
After running the experiment for several weeks i found that, in general, developers tend to be more pessimistic about the product value delivered than Product people.
However, after 3 sprints magic happened and one team reach the next conclusions inside a retro:
- Break down complex tasks
- Be explicit on value added, specially for techy tasks
- Deliver small tasks on different sprints
- Validate the value to be delivered before starting a big task
- In the planning meeting, check for tasks that will be a candidate for the Demo
Conclusions
Even if I had tried to explain the importance of these 2 Agile principles (“Deliver frequently” & “Deliver value early”) before, the team started to integrate the value delivery concept the moment they actually saw the concept in a clear, visual and explicit way.
This helped the team to start sharing ideas to improve the product value delivery, and moreover, to start thinking about the demo meeting as something useful.
Another important characteristic of the experiment for me is that it introduces a routine in the Retrospective meeting that forces the team to think about the value added which in turn brings learnings for future priorisation. I find this is more powerful than for example preparing a single Retrospective focused on value delivery, mainly because the value added is easier to see when you can compare it between different sprints.
Next steps
On the basis of these findings, we have also renamed the column “Done” and it’s now called “Value delivered” in our dashboard. Like this we have this important concept present in our day-to-day, even in our daily standups. And I will keep trying to make the team see the value of having the demo meeting — wish me luck! :D
