Common Agile Practices That Sabotage Us

Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress.  Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.

Observation:

We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.

Impact to the Team:

• Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
• Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
• Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
• Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

• Create a user story by including the user scenarios to help clarify the expected outcome and user experience of the story. This not only helps QA kick start the test automation earlier in the process but also helps Dev to understand how the feature will be used in different situations and they tend to have lower bug counts.
• Keep a user story open until it has cleared QA.  A user story is NOT DONE if it hasn’t been tested and accepted by the Product Owner.
• When logging bugs against a user story, keep the bugs as close to the story as possible. If your tool allows you to add the broken test cases inside the story, do that. Everyone should be able to quickly see which stories are not done and why.

Observation: We can’t seem to get our user stories done in a single sprint so we have the same story in several sprints.

Impact to the Team:

• Because the feature that is represented in the user story is not done for several sprints, the team’s work cannot be “potentially shippable” at the end of each sprint.
• Because the user story is not uniquely defined each sprint, it may not be clear to everyone what is expected to be done by the end of each sprint.
• The work for the user story keeps “sliding” to the next sprint and it’s unclear whether the feature is on track to be completed by the last user story that was extended.

Options to improve:

• When reviewing a user story during sprint planning, identify stories that are too large to get all of the work done; that means development as well as cleared by QA. Break up those stories into more than one by grouping a set of user scenarios that CAN be done in a single sprint and “rebranding” the user story to reflect those scenarios so that when you look at each story, it’s clear what will be delivered in each new story. They should be uniquely identified.
• Remember that at the end of any sprint, the Product Owner should always have the option to request all stories that are DONE be “shipped to production.”  If your team cannot do that, then the user stories weren’t really “DONE” in the sprint(s).

Observation: We have people that are on more than one agile team.

Impact to the Team:

• Team members that are on more than one team become less efficient because they are attending multiple sprint planning sessions, daily stand ups and working sessions.
• Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent.  For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
• Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.

Options to improve:

• This situation should be temporary.  There should be a transition plan in place so that teams have the ability to continue taking on new work and their velocity can stabilize and continue to improve.
• If people have a unique skill set and transitioning is not an option within a few months, determine which agile team has the most work for that skill set and put them on that team.  Any new work that requires that skill set is assigned to their team, becomes part of their velocity and capacity planning metrics.
• Ensure that when new projects requiring that person’s unique skill set come up, they are invited to the release planning and the user stories are appropriately written and part of that team’s sprint planning.

Observation: We have people that get moved from one agile team to another throughout the year based on projects that come up.

Impact to the Team:

• Team velocity is useless because the aggregated capacity is not constant and each team’s velocity cannot stabilize.
• Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent. For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
• Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.
• Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
• Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

• Consider that teams that are able to stay together over time become more efficient as they learn to work together, improve together and their individual skills increase.
• When building an agile team, ensure that the type of people and their skill set is appropriate for the backlog of work they will receive.  A healthy balance of development, testing and operations on a single agile team is key.
• Rather than sending people to projects, keep the same people on the same teams and send the appropriate project work to the team.  This is where Release Planning for a project will ensure that each team identifies which user stories from the project are “theirs.”