One of the most common problems with existing well-established agile development teams is that they have issues delivering value-added user stories. The team is cross-functional, has established velocity, understands roles, process and cadences. But when it comes to demonstrating the work at the end of the sprint or program increment, the value behind what they develop falls short to the eyes of business owner, product manager or different stakeholders.
Most agile change agents or coaches have seen this scenario before and we all know it is neither the team nor the agile processes. It comes down to alignment and understanding of the work being committed during a sprint or program increment. The work the team has committed to in a sprint must have alignment to the enterprise, organizational or program goals. The team, leadership and stakeholders must all be aligned on the objective of the work and how that work will provide value back to the organization. In coordination with that, there must be a common understanding of the work being committed to by all parties involved. Lack of understanding leads to development of work that does not align to the value or goals we are trying to achieve.
Because of a lack of alignment and understanding there are four core problems that arise at the team level,
Teams are delivering user stories which add no value to the enterprise or organization
Teams are committing to user stories that are complex and large which results in an inability to deliver
Team does not understand what they are trying to achieve with the user story
Completed user stories are not demonstrable
As a result of seeing these common problems too often we have developed the Rubix Cube to Value Added User Stories. This blog reviews the foundation, guiding principles and process which make this approach effective in ensuring that an agile team produces valuable user stories.
Foundation to Rubix Cube Alignment and Understanding
The rubix cube is a perfect symbol to help demonstrate how user stories in a product backlog must be aligned and understood in order to ensure successful delivery of valuable user stories. Without the understanding and alignment of the work from the end users to the team, the team is being set up for failure.
As a result, we have set up a three-tier scope decomposition which originates from the Scaled Agile FrameworkTM a decomposition of work from Strategic Themes, Epic, Features and User stories. The SAFe methodology is ideal for large scaled enterprises and can be scaled up or down, as needed, to fit any size organization. But a three-tiered system is best to illustrate the value alignment through the decomposition of work back to strategic themes and down to user stories. The key to scaling up or down this approach is to ensure that there is alignment from the top to the bottom of the framework, regardless of number of tiers.
To ensure alignment across our rubix cube, we should consider three key characteristics of each piece of scope that is critical to ensure we have a complete understanding of the work.
Details– Clear description of the what and known how of the piece of work. Identification of In Scope, Out of Scope, assumptions and Non-Functional Requirements help to articulate the work.
Benefits– Identify the value behind the work based on three categories
People – Who is benefiting from achieving this work and why?
Process – What is the benefit behind the process being enhanced?
Capability – What is the benefit behind the business or technical capability being enhanced?
Validation – Explanation of how the team, agile product owner, and other stakeholders will know that the work is complete. Details here can lead to acceptance criteria, Test Cases, etc.
Classification of the work into these categories becomes an effective and efficient way to get alignment and understanding of the work across all stakeholders.
This seems complex to complete and almost as painful as actually completing a rubix cube! Ensuring there is full alignment and understanding of work across multiple incentives and teams is very difficult. This is why, in the days of waterfall, teams created 709 pages of requirements that would take four months to complete and required signed off by every person possible and baselined so that we ensure alignment and understand of this perfect rubix cube. But today we cannot do that because market needs change too often and we cannot get the full rubix cube correct as it takes too long to complete, and the colors keep changing. The question is, what if we just want one side of the rubix cube to be perfect? What can we do to line up the colors for one side?
Rubix Cube Principles and Processes to Value Based User Stories
We are about to move into the principles and processes which will lead us to value-based user stories. Remember that we are not trying to figure out the whole rubix cube, which is impossible in today’s world. The principles and processes below will help to outline how we constantly iterate, collaborate and refine the work so that we can get alignment and understanding for one side of the rubix cube long enough for the team to commit and deliver value.