In the first part of this blog, we saw some of the issues that arise in agile development when there exists a lack of alignment and understanding of user stories in the product backlog at the team level, including the team delivering user stories that add no value to the enterprise, committing to user stories that are too complex and large, lack of understanding on the vision for the user stories, etc. So how can we get to value-added user stories?
Guiding Principles to Value Added User Stories
Knowing that we have a structure and foundation to document the work, we needed to establish some guiding principles to drive the alignment and understanding of the work. The guiding principles are all to drive a mindset of continuous iterations of scope decomposition to drive quicker value back to the organization.
Align– Align all work to benefits. The core of this entire approach is alignment to value. The value derives from the benefits the scope is trying to achieve. Value should be identified at the highest level of scope decomposition and then aligned to the lowest level. Establishing new or decomposition of value at lower levels Align Puzzle Pieces of refinement can lead to misalignment of work and non value added user stories. If, through refinement, new value is identified, it must relate back to an Epic (or highest level of scope decomposition). This could lead to adding it to or establishing a new Epic, which is specific to achieving that piece of value. Doing this will minimize the risk of gold plating and keep the work aligned to value as it was intended.
Ensure– Validate that the work can be achieved by ensuring there is an understanding of the work Alignment to value across all stakeholders. Ensure they understand the value that will be achieved after the work is complete. This is how the value is realized. In the process, we identify value by the value to people, process and capability. Validation of that value occurs in the form of people, processes and capability to ensure the value was achieved. Doing this at every level of the scope decomposition ensures that work stays aligned to the value achieved.
Demo– Ensure pieces of work are demonstrated as minimal viable product. Sprint or PI Demo are the hardest of the agile process to fully achieve because it comes as an afterthought. Mid Sprint the team suddenly remembers that we must demonstrate something, so they pull together whatever they can and hope it works at the demo. For demos to be effective, thinking of what pieces of work tied together can be demonstrated at all levels of scope decomposition is critical. Splitting a single Epic into two demonstrable pieces of value allows for easier prioritization, better understanding, effective execution and value added demonstrations. Consider demonstrations when breaking down work.
Process to Value User stories
The process outlined below is not linear and is very iterative. Think back to being a kid working on that rubix cube: If you kept at it for hours, it would eventually aggravate you enough that you would throw it across the room!! Do not let that happen here. Start writing, have a conversation with someone (get their feedback), revise it, and then step back and see where you are. Then attack it again. It took my whole family an entire summer to get the rubix cube perfect. Don’t expect to lock down scope in a day and throw it over the wall. It takes multiple iterations to get it right.
Below is more detail about the process.
Write – Get the information down on paper. The culture of meetings and discussion too often creates more confusion than clarity when it comes to alignment of scope and decisions. Verbal communication can lead to misunderstandings if not framed properly. As a best practice, write and allow enough time for people to read, react and ask questions. This aligns to the 3Cs in user story writing. Ensure the card is established first so that there can be an effective conversation which leads to confirmation.
Revise–Do not be afraid to adjust and create new Epics, Features or User Stories. Do not think of this as a traditional work breakdown structure. At the core it may feel like it, but the principles and process enable iterations of determining the right scope. Feedback and conversation between the different levels of scope also helps to articulate the scope and validate true minimal valuable products. The management of these backlogs is an active discussion from top to bottom until the time of commitment at the team level.
Reflect– This rubix cube can get tricky as Epics and Features start to get split into 2 or 3 different Epics and Features. There are two key pieces to reflect on to ensure everything is staying aligned. First look across the features details to see if all major pieces of work are lining up to the proper sub pieces. Next ensure that when each piece is complete, it validates the benefits of the macro piece of work. This is critical to help ensure alignment. Constantly reflect and adapt to ensure the sum of the breakdown of work achieves the whole.
Call to Action
We have seen teams and groups of teams called failures because they were unable to deliver value added user stories. This was not because the team was not effective or did not have the proper skill sets; it was because the team was unable to get alignment and a full understanding of the work.
In today’s environment, this is becoming the norm. The rubix cube approach to value added user stories helps to manage this unknown by ensuring that work is aligned to value and understood before it is committed to. It also helps to establish an iterative approach to scope refinement. If you are having challenges with delivering value added user stories, I ask you to try it, and improve the process.