One of the key factors of doing Scrum is that we end up provide Business value at the end of every iteration. That is why it’s gradual, yet continuous and stable. There are many, many teams that do Scrum but they fail in defining sprint goals and the added value that will be provided at the end of that iteration. If there isn’t business value or potentially releasable products at the end of the sprint, it’s not Scrum. Only Stories added to a timeboxed sprint with some output sometime.
That is another matter. Even if there isn’t a clear product increment at the end of a sprint (or none), performing iterations with good predictability is already a win-win for the team. But not Scrum. Some organizations of reference here such as Spotify have this (in my opinion) funny concept of releasing unfinished features but hide them in the production environment until they’re ready. Let’s say that out of the features A, B and C, the last one isn’t ready by the end of a Sprint. Just partially. It gets released anyway but it isn’t shown. It’ll maybe be completed in the next iteration. And still, features A and B are actually there, providing the requested value at the end of the iteration.
However, what does Business value mean, exactly? I find this quite a big problem, as the answer will depend on who you ask within the organization. It should be plain and clear for everyone, but sadly it isn’t. Is a proof concept business value? Is an element of quality introduced within the development cycles such as automatic deployments or regression tests of business value? Or just the features that are released live, and nothing else?
For me, like everything in like, is both yes and no. There isn’t a simple answer here. A few days ago I engaged in a discussion with a product owner, as we were discussing potential risks on the current iteration and we highlighted the lack of business value in the output if the stories at risk didn’t get completed. But the funny bit is that, for me, what didn’t have business value for the product owner did have it for me.
After having an internal debate about this, and asking for feedback to some of my friends, an ex-colleague of mine recommended to me the book The art of business value by Mark Schwartz. And my, what an interesting read! Still doesn’t provide all the answers, but it’s a very thoughtful reflection from all angles.
There are several areas to highlight:
- Understanding the problem: what does business value mean for us and for our peers?
- What are the risks of not delivering that business value? (Cost of delay)
- Bureaucracy as an impediment for finding the right definition.
- Company culture: pros and cons, logistics between departments.
- Silos: how not having all aspects into account end up affecting the definition.
- Defining specifics: always, take a step back and look around you after a long assessment.
- Creating outputs: What have we delivered? How did we agree to the business value? How can we improve it?
These are the hot topics. But for me, the most important bit is that Agile practitioners seem to read many things about the so-called business value, but not only the definition is ambiguous, but also doesn’t mentions ways to measure its bigness and metrics behind that value. Can we relate story points to value? No. Can we measure the cost by T-shirt sizing? No. Can we do all of this at feature or epic level? Maybe!
Defining and sizing business value can only be achieved by agreeing on a strong, clear definition of done, check where all points between roles and departments meet (return of investment, quality, added value for the customer), maximizing communication to avoid misunderstanding as much as possible, isolate and have into account financing whenever needed, and a big etc. Business value is a very tricky and complex concept!
Again, like with many other aspects in Agile, nothing is truly achieved unless we possess a key element: trust. Certain roles will wear the I-know-better hat, and that is utterly wrong. Expertise in a role should be at the service of the whole team, but also the other way around. Every member has its own voice and likely something to say about it. Only by fitting all the pieces we can be satisfied enough with the outcome. And that is also how an organization and its teams find their identity.
Last but not least, finding that precious definition is something that builds up but is likely to fall backwards unless there’s a list of commitments. To understand in a broad, abstract concept that business value means for the team, for the departments, for the organisation. Alignment is needed and have to be carved in stone, but realign and redefine bits when necessary. Never forget the steps taken to get where we are. And everyone’s cooperation is needed through the Scrum iterations. I found retrospectives incredibly enlightening in this aspect.
In a nutshell, business value is for me, something that:
- serves the purpose of the strategic roadmap of the organization.
- serves both the purposes of external and internal quality standards.
- is built with continuous improvement.
- Is agreed at all levels, not just the business and strategy ones.
- provides return of investment (not just from the external perspective).
- evolves into something complex and perfected.
What are your thoughts?