An error doesn’t become a mistake until you refuse to correct it.
John F. Kennedy
As a product ownership expert and coach, I see teams make a lot of the same mistakes that compromise the very progress they are trying to make. The paradox here is, these patterns and mistakes are done with good intention, for what seems to be the right reasons, and sadly create more challenges. Ultimately, slowing the team’s progress towards fast, high quality, and relevant products for their customers and users.
What many of these patterns come down to is a misunderstanding of what it means to “be” agile and truly act out our roles and as a team in an agile way, following the values and principles that the term “agile” was founded on. Here are the most common mistakes I see, ways they go against agile values, and how to fix them:
Calling everything on the Backlog a User Story
User Stories are about users, plain and simple! They are about the things users want to do with the product, their interactions with the product, and their goals when using the product. If your backlog is full of technical debt, and tasks the team needs to do and the items are not about users, then they probably shouldn’t be called “user stories”.
Now, that being said, user stories are a common agile technique to enable writing backlog items because agile values and principles ask us to create units of working software, that is working from a user point of view. Therefore, user stories, when written well and from a user point of view are able to be demoed and shown to a user for feedback, and this values working software as the measurement of progress.
Technical Things as User Stories
Technical debt, component level technical tasks, phased tasks, and other things not from a user perspective simply fit somewhere else into how work gets done. Most technical tasks can be sub-tasks of the real user story, that also can be defined in the teams’ “definition of done”. Sure technical debt is something the users really don’t experience. So, if the user will notice or be impacted, then it can be a user story and can be written as a user story from a user point of view. The team can break up that story into smaller tasks, just please call them team tasks or subtasks. Additionally, users are not meant to be other systems or other teams. Users mean, end-users!
One way to look at this is that if the team is not delivering user demo-able things, then it’s hard to quantify the value the team is delivering. Organizations and those that pay for the products we build want product teams to deliver value to the users of the products. User stories that are written from a user perspective will align to show the team is delivering value, not just working really hard. In order to fix this, make sure your user stories are from a user action/goal point of view, and that you could demo the user story when it is complete to a user and receive feedback from them. If you are dependent on another team, or they are dependent on you to make something demo-able, then share the user story, create the demos together, and enjoy success together.
Ignoring Best Practices
If your team cannot find a way to work from a user point of view or collaborate with other teams from a user perspective, then user stories may not be the right choice. Most teams that struggle with this idea think that they are unique and need to go around the best practice; and after years of coaching teams on this challenge, I have yet to find a team that hasn’t made these best practices work. In reality, It’s more common that a team is tired of trying new things and not confident how to make them work. Honoring best practices can reinvigorate team motivation.
Team Assigns User Stories to Individual Team Members
A common shift for many when transforming to an agile way of working is shifting from an “I” to a “We” mentality. With user stories, the challenge comes when teams assign user stories to individuals. User Stories are units of work for the team, not a person. To complete a user story a team needs to complete all the work needed to demo the story from a user perspective, and this includes work that typically uses many different skill sets; hence the whole team. The front end developer, back end developer, database admin, API developer, etc…. which include the contribution of the QA, BA, and other supporting skills. Estimating user stories is a team estimate, not an individual estimate, and completing all the work is a team activity, where the team uses the various skills of the team members to get the work done.
Imagine the overhead time saved by managing this way. Allowing the team to self organize around the work together to provide a user story with clear demo-able acceptance criteria from the user point of view. Whereas, delegating every little task as a story and managing the workload equates to rising overhead. This is where the agile value and principle of self-organizing teams comes from, and how user stories fit in. When the team is given a clear user story with a clear user action/goal and communicates about the user scenarios with the product owner and stakeholders, it then allows the team to figure out how to deliver, estimate, and commit.
You’ve Got Options
Consequently, to fix this, start working together as a team on the same story at the same time. Use your daily stand up meetings to plan how the team will work on the next story together rather than give separate status updates. Yes, the daily stand up is a planning meeting, not a status meeting. When you are all working on the same thing at the same time magic can happen and things get done fast! To make this work the user story needs to be from a user point of view and the team needs all the skills to complete the work. If your team is dependent on other teams or skills, you have a few options:
- You can wait until those people/teams/dependencies can work on it at the same time and add a blocker to the user story in the meantime. Do not add the story to the iteration until all dependent work is done, making it part of “ready” status. The downside here is that managing all the blockers and dependencies prevents you from helping the team move fast.
- You can do the work, and add a blocker while waiting on the other teams to complete their work before demoing it as DONE. The downside is that this can increase WIP (work in progress) and add to the teams’ overhead to manage a lot of WIP.
- Work together with the other team at the same time and demo it together.
If a user story does not need all of the team members’ skills, you can have the left out team members chip in and learn new skills, or work on something else that makes sense towards meaningful progress for the team.
I hope this helps with your road to more “being” agile and the path to agile maturity. Let me know how and if one of these options worked for your team! I love collecting success stories and best practices.
Experience is simply the name we give our mistakes.
Oscar Wilde