It seems intuitive that once you have sized your stories and agreed on the sprint backlog, it doesn’t really matter how you do your stories (e.g., in what order, which one’s first, how many you start together). After all, you have sized the sprint, and you feel confident that you should be able to do all those stories by the end of the sprint. Let’s examine a few scenarios.
Scenario 1: Starting multiple stories in parallel
Some would argue that you can start with as many stories as can possibly be started (given the dependencies), because you would unearth issues earlier and get more time for resolution. I have seen some developers starting multiple stories in parallel, and continuing to work on them almost until the end of the sprint. As a result, it puts too much pressure on the tester, and in case there are defects, the developer does not have sufficient time to address all of them. This approach has another effect in that the timebox is over, but the Definition of Done (DoD) for many stories has not been met, even though tangible progress was made. The final outcome is that the velocity for the given sprint suffers. In the longer run, the velocity fluctuates wildly over sprints.
It is not a good idea to start too many stories at one go in a sprint. Is it worthwhile to restrict the number of stories to start, borrowing from the Lean-inspired practice of limiting the work in progress? Let us explore this next.
Scenario 2: Picking up a minimum number of stories
Deriving a lesson from Scenario 1, a more meaningful approach would be to start with fewer stories. The focus should be on picking up the minimum number of stories to keep the development team well engaged. Only when the team finishes some of the stories can they pick up more stories. Because the team finishes one story before starting a new one, the velocity picks up much earlier in the sprint, and the team is likely to end up with a more stable velocity pattern across the sprints. This will also give more room for QA to provide timely feedback and the developer to apply any corrections.
This is a happier scenario, compared to Scenario 1. Work on fewer stories and focus on finishing open stories before starting new stories. It’s worthwhile to focus on the idea of limiting the work in progress and focusing on the Lean philosophy of “stop starting and start finishing.”
Scenario 3: Calculating the cycle time of a story
Let’s push the curve a bit more. What if we brought another variable into play — the cycle time of a story?
Before answering this question, here’s a short definition of cycle time:
The cycle time of a story is the elapsed time between the start and finish of a story.
The cycle time can be broken down into two parts: the worked time and the idle time (or waiting time).
Cycle time = worked time + idle time (or waiting time)
Let’s come back to the original question: What if the cycle time of a story becomes a focus area? An initial response would be: How does it matter? And a likely argument is that even though there are idle times between work times, the resources are not idle. Consequently, no resources are wasted; it’s that only the work is waiting. So why should we bother? Let’s analyze this with the help of a brief example.
Suppose in a sprint the sprint backlog has three new Web pages to be integrated into a microsite, among other things. A story (in the sprint backlog) is defined as a new, fully developed Web page integrated into the microsite. Therefore, we have three stories, with the DoD for each page as a Web page designed, developed, integrated into the microsite, and tested. The tasks (flow) can be described as follows:
- The UX designer designs the basic wireframe and content for the Web page.
- The visual designer produces the multimedia content for the page and identifies the visual treatment of the page.
- The UI developer develops and integrates the Web page into the microsite.
- The QA team tests the page and validates that the page meets the requirement.
This flow gives the impression of a Waterfall, but the story is small enough to be started and completed within the sprint, over three to four days. The flow of work is depicted in the following illustration.
Now let’s review what happens when you focus on cycle time, and you try to dig deeper into each step. Here are some interesting findings (from a recent project in which the author was involved) for the above scenario:
- Bottlenecks are identified: Looking at this flow, it becomes evident that the visual designer takes more time than other development team members in the workflow. This reveals that if there is higher visual design capacity, then the story can be finished faster. Some options to consider include adding more visual design capacity, or getting other team members to contribute to the visual design (if they are cross-functional or generalizing specialists). This leads to a shorter time to value.
- Hand-offs among different developers are much more efficient: Just because the focus is on cycle time, the developers ensure rapid hand-off to the successor, as any delays would increase the cycle time measurements, thus leading to a shorter time to value.
- Rework is reduced: After the content is developed (step 2), the build and QA (step 3 and 4) finish quickly (as the result of near real-time hand-offs), which generates early feedback that can factored into the subsequent develop-and-build activities rapidly. This reduces rework, as the QA feedback is available faster.
- Inefficient practices are surfaced: A deeper dive of tasks during the review of the build cycle time (step 3) revealed that the developer was taking a significant amount of time in manually replicating the code from the development to the QA environment before releasing it for testing. This led to an improvement story for automating the code refresh.
A focus on cycle time helps unearth some surprise improvement areas, improved collaboration, reduction in rework, and shorter time to value. While the benefits of a cycle time may differ in other situations, this analysis is expected to surprise teams with some valuable findings.
The overall conclusion is that while Scrum is focused on planning and execution of sprints, it is worthwhile to look at the work in progress and cycle time of stories to amplify its benefits further.