Storytime

By Bryan Finster | Wednesday, January 27, 2021

ScrummerFall

Jackie is a buyer who needs better tools for forecasting demand so she can make better-informed decisions. She has a list of high value features she needs, so she contacts Dana, the product owner for the forecasting application, to request changes.

Dana discusses the features with Jackie and writes user stories for each feature with acceptance criteria for each story and adds them to the backlog. Since Q1 is half over, Dana schedules the new request to be discussed in the planning meeting for next quarter’s goals. There are lower value features prioritized for Q1, but it is important to prevent negatively impacting Leadership reporting on “committed vs completed”.

As the new quarter begins, Dana schedules time with the development team to discuss the upcoming features she committed to delivering and prioritizes the stories to be delivered on the first monthly release. The development team begins working on the first 2-week sprint while the testing team begins to build the test automation based on the stories.

At the end of the first sprint, the team submits their changes to the testing team for the testing sprint. However, on the second day of the next sprint, several defects are reported from the testing team, and effort on both teams shifts from development to triage and defect resolution. During the triage process, it’s discovered that the testing and development teams understood the acceptance criteria slightly differently on several stories. Dana schedules a meeting with Jackie to get clarification on how those stories should behave. In the meantime, the development team continues working with the testing team to resolve the defects in the remaining stories.

As the end of the second sprint nears, several of the stories are still impacted by defects and by the pending meeting between the product owner and business user. However, the team begins the process of preparing their change request for the stories that have passed testing for review by the change board and prepares their deploy documentation for the release management team.

After the Change Management Board reviews and approves the release and backout plan, the Release Management team schedules a time on Saturday for the development team to monitor the change after the release team deploys it. During the release, several issues occurred with the release plan that required the development team to make emergency changes to stay within the release window. This turned a scheduled 1-hour process into a 36-hour marathon to patch things so they would be ready by Monday morning.

On Monday morning, Jackie comes to work to try out the new features and is a bit confused. Many things she expected to be delivered have not been. In fact, the stories that have been delivered do not work the way she thought they would. Jackie begins creating defects and eventually emails Dana to request a meeting to find out why so little working software was delivered 2 months after her initial request.

After meeting with Jackie, Dana contacts the development team to find out why the plan failed. Brent, a new developer on the team, suggests that the most effective approach to discovering where things went wrong was to have a postmortem of the last two sprints that included representation from Jackie, Dana, the development team, the testing team, the release management team, and change management to have a holistic view of the entire delivery flow.

Identifying Causes

At the postmortem, Brent facilitates the discussion to find the pain points in the current process. He focuses the attention on “what” and “when” instead of “who”. This result took a team effort by all stakeholders after all.

There were several handoffs of information between Jackie, Dana, the development team, and the testing team. Each of those resulted in a loss of context.
Even though this work was a higher priority than several items on the previous quarter’s plan, it was scheduled for the next quarter to prevent poor reporting on the “committed vs completed” tracker.
The first chance Jackie had to give feedback was after delivery to production.
Testing was seen as the responsibility of the testing team. Quality feedback to the development team was delayed until at least a week after development had completed. In addition, each team had an alternative understanding of some of the features.
The delivery process was manual and never verified.
Because the manual change process required so much time, the team raced to complete work to make the cutoff date without sufficient quality feedback and created more issues as a result.

To begin resolving these issues, they focus on the biggest problems: an unreliable method to deliver changes and poor communication. They decide to make the following changes:

They decide that Jackie and Dana will collaborate on reviewing the backlog frequently and will adjust roadmap priorities as needed rather than strictly adhering to a quarterly plan.
Brent suggests that everyone will have more success if the communication paths are shortened. They decide that Jackie and Dana will meet frequently with the development team and some of the testers to refine work together as a group. They will work together to ensure that there are comprehensive testable acceptance criteria defined for each story and that no work will start on a story unless all stakeholders agree.
The development team will schedule small demos twice a week with the product owner and once per week with Jackie to get more rapid feedback. In addition, effort will be given to improving the testing process over time with the goal that all tests are maintained by the development team. This will prevent two unneeded handoffs, two different misunderstandings of the stories, and the delayed quality feedback from waiting on another team.
Development effort will be diverted to automate the release process and to ensure tests are executed as part of that process. Also, a representative from Change Management will work with the team as they build the delivery automation to ensure it contains the checks they are looking for in CAB and to certify their delivery process can be exempt from manual review.

Iterating to Better

After a couple of sprints of dedicated improvement efforts, things have improved greatly. There is still much work to be done on improving the testing process, but work is better understood and fewer defects are occurring. Jackie has transparency into how work is progressing and can make adjustments to stories as she sees her ideas come to fruition and decides additional changes may be needed to achieve the value she expects. She can also look at the backlog and remove things that are no longer valuable. The development team also has a deeper insight into the business goals Jackie has and begins suggesting improvements to her as well. Dana has a much clearer picture of what the priorities are. As the test and delivery automation improves, she can spend more time on product strategy instead of fighting fires and managing business user expectations. Best of all, the team has an improvement plan that will allow them to begin delivering changes during the working day safely.

Written on January 27, 2021 by Bryan Finster.

Originally published on Medium