Creating an ATDD Ready Sprint Backlog in Scrum

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

Creating an ATDD Ready Sprint Backlog in Scrum

Ralph Jocham, effective agile, https://effectiveagile.com/

Scrum is a very powerful framework to drive out the right requirements and thereby delivering the best possible product in a given time frame. This is made possible by frequent inspection and adaptation based on ongoing transparency. One of the empirical process-control-feedback loops is the Sprint Review in which the product increment is being made public for review and feedback. This feedback helps to discover new features, remove unneeded ones and alter them based on the gained insight. It is nothing less, but effective just-in-time planning to maximize the ROI. Most of those new features are broken down into requirements during the Product Backlog grooming sessions and subsequent Sprint Planning meetings. Scrum and the Scrum Guide do not mandate how you write your requirements, many prefer User Stories but any other format is ok as well. The same applies for the Sprint Backlog, Scrum only requires that you have a plan to deliver the selected Product Backlog items and that at any given moment during the Sprint you know how much work is remaining visualized with the Sprint Burndown, another popular Scrum practice. As you can see, Scrum is a rather minimal framework, with only a few strict rules and many possibilities to apply proven practices in your given context.

Sprint Backlog

As mentioned before, the Scrum Guide defines the Sprint Backlog as the set of Product Backlog items selected for the Sprint plus a plan for delivering the Product Increment and thereby realizing the Sprint Goal. One possible enhanced practice of a plan can be to specify the Sprint Backlog with a set of examples. It is a rather new practice, but gaining more traction in recent years.

With this approach you create an extended implementation of a Sprint Backlog that responds to two fundamentals questions:

How can the Development Team be sure that the plan is adequate in fulfilling the underlying requirements?

How can they foster collaboration and confirm repeatedly on a recurring basis that the software under construction always meets the evolving requirements?

Planning and driving a Sprint with examples allows the Development Team to better understand the requirements. It seeks to add an extra level of conversation to eliminate the communication gap between business and the team. This is done by illustrating each Product Backlog item with a cohesive set of concrete examples, expressing the success criteria. These examples, which are nothing less than a provable plan, will guide the Development Team to build the right product right. During the Sprint, by translating these business-facing examples into automated tests, we gain more transparency about the business need and simplify the "inspect and adapt" cycle.

For many of us, it is assumed that the plan of the Sprint Backlog is a list of technology-facing tasks ignoring the 'why' in the first instance. The underlying assumption is, that when all tasks are completed, the Product Backlog item will be 'done' right.

Creating an ATDD Ready Sprint Backlog in Scrum

Figure 1 - Classic Sprint Backlog

Splitting requirements into tasks can help developers to think about the amount of work involved and leads to more accurate estimates but it is a poor strategy to foster collaboration. In the end, the progress during the Sprint is measured with the completed Product Backlog items. A Sprint Backlog that is centered on the validation of business needs helps to be more effective in delivering the business value right.

The Underlying Problem

Doing the right thing and doing the right thing right - this is the paramount problem of software construction. Even though Scrum helps trawling the right requirements through ongoing Product Backlog grooming, almost invariably there is a communication gap -- a misunderstanding between Product Owner and the Development Team. The reasons for this is that requirements are ambiguous, tend to be abstract and often omit the 'obvious' details. Therefore, they are hard to grasp, not tangible and cannot easily be projected into a cohesive solution. Furthermore, if we purely plan the Sprint with a list of tasks that ignore the channels of communication with stakeholders, this adds risks that can cause too much Sprint Backlog variation and make it hard for the team to reach the Sprint Goal.

The described practice suggests an alternative strategy to plan the Sprint. This has major impacts affecting the Sprint Planning Meeting, the Daily Scrum, Sprint Review and the Grooming if you choose to do it. During the Sprint Planning/Grooming, the plan produced by the Development Team is augmented with a set of concrete examples illustrating each business requirement. Because the work is now also expressed in terms of business requirements, during the Daily Scrum, each team member can easily focus on the bigger picture and align with the 'why'. There is no lack of awareness of the Sprint Goal. Furthermore, by translating the business-facing examples into automated tests, it enables the Development Team to systematically and quickly inspect during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.

Automation

Assisted by the business-facing automated tests, the Development Team can easily confirm that all examples work successfully. This changes the dynamic of the Sprint Review because the conversation is much more about the future requirements than the work done during the Sprint.

We apply the practice in two stages:

During the Sprint Planning Meeting and/or Grooming, the Development Team illustrates each Product Backlog item with a cohesive set of examples and related data in order to create a plan. These examples are concrete, tangible, provable and automatable.

During the Sprint, the Development Team translates those examples into tests in order to inspect the Increment under construction. These tests should be automated to facilitate fast regression testing.

In addition to the regular tasks, each Product Backlog item selected for the Sprint is augmented with a set of examples and each one illustrates the expected behaviors. These concrete examples communicate and validate the acceptance criteria.

Creating an ATDD Ready Sprint Backlog in Scrum

Figure 2 - Sprint Backlog specified by Examples, ready for ATDD. The dark yellow PBIs (flip side) contain additional examples and related test data. The orange-brown tasks are ATDD related work items

The Sprint Backlog enhanced with a set of examples in form of automated tests, is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint. These concrete examples provide enough detail so that changes in progress can be understood throughout the Sprint, specifically during the Daily Scrum. If a new example is required, the Development Team adds it to the Sprint Backlog. When an example is added, the estimated remaining work for the whole Sprint is updated.

By translating the business-facing examples into tests, we enforce an additional level of communication, which answers the question: 'How can we prove, that the Increment is right and working correctly?' It is this conversation that puts the whole Scrum Team on the same page.

Planning and inspecting with examples will fundamentally improve the conversation between the Development Team and the Product Owner. Card, Conversation and Confirmation as proposed by Ron Jeffries is put to it's best. As a result of correctly implementing this practice, no Product Backlog item should be rejected by the Product Owner during review without good reason as not "Done". This result occurs because, each day of the Sprint, all members of the Development Team focus on the bigger business picture and align with the 'why' of the requirements. Also, this approach helps to horizontally scale the communication of the business intentions when working with several Scrum Teams under one Product Owner and one Product Backlog in a scaled Scrum environment.

ATTD and TDD in Action

The following schematic flow visualizes the steps of driving the development guided by examples in a test driven development fashion. For every User Story from the Product Backlog that has been put into the Sprint Backlog in alignment with the overall Sprint Goal, a set of acceptance criteria are defined. Each of those acceptance criteria, one or more examples are specified. For each example an acceptance test is being written which will fail as the business functionality has not been programmed yet. The next step is to program the functionality in a TDD way. At some point the test of the example will pass and turn green meaning that all unit tests are passing and the acceptance test is working according to the example. Now is the right time to refactor the code base to keep it clean.

This approach seems to be time intensive at the beginning, especially for developers not well versed in writing tests first. However, in practice it is the basis for a long time sustainable high product development velocity. It allows for fast regression testing which is mandatory when throughput and quality are paramount.

Creating an ATDD Ready Sprint Backlog in Scrum