Why we do what we do in scrum?

Scrum Master tip #5

Remind the team of an importance of data and conclusions during the sprint review

Planning, sprint, review, retrospective, planning, sprint, review, retrospective…. Such a cycle gives a sense of control, reduces complexity, sets a certain framework and… enables adaptation to changing business requirements. Exactly - do we actually use the latter possibility? From my observations, a regular cycle that has many advantages also has disadvantages. Unfortunately, it can lull the vigilance and make the team feel complacent because we are achieving sprint goals! We focus on the quality of what we produce, we find new bugs and fix them, we create tools to improve the process, but... Does it all make sense for the user? Do people need new functionalities that we offer? How popular is the product after the last changes have been made? What the customers say? What does the competition have? Which channels of reaching the customer bring us the most profits?

Without answering the above questions, our product will not be embedded in the market reality. And this may hurt us in the future. A lot.

Detachment from the business context is a serious sin of a scrum. Fulfilling new requirements on the basis of a backlog composed by the Product Owner, who - I strongly believe - collects feedback and talks to the sales department, is just one step towards being close to the customer. The scenario, however, can often look like this: we move forward, deadlines are chasing us, we make more tasks from the backlog, the atmosphere is great, the performance is great, we draw conclusions from the perspective of the last sprint - we complain a bit about the ASAPs, but at the end we would clap a little for ourselves as we have managed to do more than expected. Then we would show the result of our work at the sprint review, listen to comments, listen to new sales ideas, and keep going. And then suddenly… a CFO comes and says that the budget is a mess, that sales is too low, we have huge costs, and poor profits. Sales department says - development is too slow, development says - we have a great product, but sales cannot sell it. And so we would switch arguments and look for the guilty ones. And that's not what scrum is about.

So what can be done differently to avoid difficult situations like the one above? Remember the three pillars of scrum: inspection, adaptation and transparency. Inspection and adaptation is not only a sprint review, retrospective and daily scrum. It is also an appropriate preparation for these meetings. It is worth, therefore, that the Scrum Master in conversations with Product Owner remind about paying attention to the fact that the PO should take care of regularly showing everyone (in line with the principle of transparency) the statistics – how our sales is going? What is the conversion from tests to sales? What did the introduction of the new functionality give us? How much did we spend and how much did we earn? How do we look compared to our competitors? What do analytical tools tell us? How has our budget changed over the course of the quarter / year?

It would seem that these are data that the team does not need to be interested in. In my opinion, however, full awareness of the business context builds responsibility for the created product and gives greater opportunities for discussion and involvement. It is no longer possible to say: "I didn't know", "it's not my job", "it's not my fault". Everyone who works on the product in any way is accountable for it and for the team. This kind of commitment is only possible if we fully understand and implement the principles of transparency, inspection and adaptation.