It's so easy to forget the why when the feature requests already tell you what you're supposed to do. But something's wrong. It feels like you're going back and forth and sideways, just like a wobbly wheel. It's hard to get a grasp on what you're actually working on and it slowly affects your work satisfaction and team morale.
As a developer and Product Owner, I've experienced what the lack of clearly communicated values can do to a Scrum team and its product. In this article, I explore the importance of transparent value in various elements of Scrum:
- Product Vision,
- Product Backlog Items,
- Sprint Goal, and
- Sprint Review
Product Vision
The Product Vision provides guidance. It describes what we want to achieve and why, and who we want to achieve it for.
I've worked on a couple of projects already where the developers didn't really know what the Product Vision was. There were two reasons for that. Either the Product Vision wasn't communicated clearly, but the Product Owner tried to keep things aligned with the vision. Developers also make decisions while they work on the product. Therefore it's crucial for them to also know what the long-term goal is.
In the other cases, there simply was no vision - or rather, the vision was like a leaf in the wind. In my experience, this has the most negative impact on team morale. A lack of vision often results in evaluating, planning, and developing features only to discover late in the process or afterwards that this feature isn't needed, or essential requirements and specifications were missing or wrong. Again, and again, and again. Besides the confusion, it also gives the feeling of investing a lot of effort to produce fancy waste. The constant change of direction can cause more impediments with external dependencies and in the stakeholder communication. All of this resulting in a team of developers that - in the best case - stop being interested in and caring for the product.
Product Backlog Items
The lack of a proper product vision often also causes the lack of communicated value on Product Backlog Items. It should always be clear which user need causes a Product Backlog Item. The solution to that need should be open for discussion and experimentation and is therefore optional! If the provided solution is already verified, the item should still state the value it's expected to achieve. This ensures that team members still think about it and challenge the suggested solution if they can think of potentially better ways to approach this need.
Providing the expected value also supports keeping the focus on what you want to achieve with this product. Items that provide value that doesn't contribute to the Product Vision can be easily identified.
Having the value on each Product Backlog Item nurtures team alignment and the team's engagement. As a consequence, the team is more likely interested and invested in the product, which has a positive impact on the team's mood.
Sprint Goal
Most Scrum teams I've worked with as a developer struggled with defining Sprint Goals. Sprint Goals state the main value the team wants to create in the Sprint. They, therefore, provide guidance, focus and a common ground to work with. In addition, without a proper Sprint Goal, it's far easier to fall into the trap of making the Daily Scrum a reporting meeting instead of a working and work coordination session.
When Product Backlog Items aren't prioritized (correctly), Sprint Planning is difficult and the team's planned work items are all over place, providing no clear value and thus no clear Sprint Goal. Usually, this is a consequence of the lack of a clear Product Vision and/or lack of value on the Backlog Items. Sometimes, there are other reasons, like availability of the Product Owner, or lack of ownership.
Sprint Review
It's important to communicate the Product Vision and the Sprint Goal in the Sprint Review. It provides context for what the team aimed to achieve and reminds the participants of what parameters to base their feedback on. I've attended reviews that lacked this clear communication and thus opened doors for feature requests that were irrelevant for the current product vision. It also opens doors for turning this working session into a reporting meeting.
Another effect this can have is that stakeholders stop attending the Sprint Reviews. Stakeholders are usually very busy, so it's crucial for them to understand why it's important that they attend and provide feedback. Providing context makes it easier for them to contribute and thus provide value for the product development.
Takeaway
- Gaps in value communication cause confusion and wasted effort.
- When we focus on the 'why' in what we build, we increase team and stakeholder engagement, product quality, and team satisfaction.
- When you define the destination, the path becomes clear and is more enjoyable to follow.
Can you relate to any of those experiences? Where have you encountered gaps in value communication?
Thanks for reading and keep asking 'why'!
Top comments (1)
Great read. Unless we know the business outcome, what we are building may not make sense for the customer.