Output vs Outcome
In many “agile projects” in which I worked in various roles, the question came up again and again: How do we measure whether the team is good or bad? How do we measure the team's performance and have the transparency and knowledge to know whether we need to intervene to regulate or support?
First of all, these are the wrong questions, but if you come from classic project-oriented development, you will ask yourself these questions. The metrics that Scrum brings with it, Burn Down Chart and Velocity Chart, are very often used here.
While the burn down chart only provides insignificant information on the above questions - after all, we are only measuring the progress of the sprint - the velocity chart should be completely misunderstood and therefore misinterpreted in 99% of cases.
In almost all projects, this was used to “measure” the implementation performance of the team and compare it with other teams. A parameter was needed to measure the team's output and that looked pretty good. I can see every sprint how many story points the team has completed, how much flow I have. If this does not increase continuously, I can take measures to ensure that the team works better and completes even more tasks.
Clever teams naturally take advantage of this. They make the tasks smaller so that more tickets can be included in the sprint. They value the tickets more highly so that even more story points can be processed.
Where does this obsession with the output of a team come from?
It comes from the industrial world. In the industrial production of goods, it is common practice to increase profits by increasing production while maintaining quality and production time. In other words, I produce more of the same product in the same time and with the same quality. This way of thinking also characterizes the leading minds in a project: I only have to increase the throughput and I immediately create more work, produce more for the project.
This is also how sprint planning usually looks in “agile projects”. Every sprint should increase velocity. More tickets, more story points are to be implemented.
And this is the big mistake. Intellectual work cannot be scaled at will. Problems in the development of software are always individual and different things contribute to the solution of the problem.
Starting with the person who is supposed to solve the problem, through to their working environment, the programming language used, the frameworks employed and many other things that influence the implementation or solution of a problem.
At the end of the day, the output that our developers deliver does not affect the quality of our product. The customer or user of our applications gains nothing from us doing as much as possible. We need to move away from an industrial focus towards a focus on what benefits the customer the most.
Output vs Outcome
This is where the outcome comes into play. Outcome is the actual (added) value that the customer/user receives directly or indirectly from our development. Measuring this is of course somewhat more complex and requires the product owner / business owner to have a very broad knowledge of the market and the customer. In addition to an effort estimate, I now have to quantify each story and each epic with a corresponding business value.
Of course, this is only possible if I can estimate the value of the story for the customer accordingly. This is probably a major challenge for many product and business owners.
We then no longer measure the throughput of tickets, but the business value generated per sprint. The units of measurement for our teams have therefore changed in terms of the added value they generate for the customer. This can certainly vary per sprint, but technical debts or improvements in particular can be realized much better in a timely manner in product planning by quantifying a value for the customer than is normally the case.
However, it is also important here to keep a critical eye on the figures, as there are always ways to shift the original purpose in a different direction for all key figures.
