Agile Thinking: Stop Starting, Start Finishing

Limiting “Work in Process” (WIP) items is one of the key ideas behind Kanban and Lean approaches to developing software.

URL copied!

Categories: Agile

Limiting “Work in Process” (WIP) items is one of the key ideas behind Kanban and Lean approaches to developing software. Having too many WIPs might make it look like everyone is sufficiently busy, but there’s really no functional outcome for the end user.

In my experience, it is much more important to work towards completing the user story — in other words, to stop starting and to start finishing.

It’s natural to assume that this “stop starting, start finishing” philosophy is limited to Lean and Kanban methodologies. After all, Scrum works so well that it doesn’t run into WIP issues, right? Wrong! Let’s look at a typical Scrum standup:

In this example scenario, the project has around 9-10 team members. At the beginning of the sprint, the team creates subtasks for each user story together. The idea behind this method is that any team member should be able to pick up any subtask at any point in time — thereby limiting roadblocks or delays.

During the Scrum standup, each team member shares what he/she did yesterday, what he/she will be doing today, and if there are any impediments. Although this approach provides a decent insight into individual tasks, it fails to provide a broader progress indicator on how close the team is to completing the individual user stories and thereby the sprint. Instead, a better idea is to let the team assess how everyone can collaborate and help each other to move the user stories to the DONE column.

Now you’re probably thinking, “That’s an interesting theory, but is it really necessary? After all, the end user will only see the finished features after the sprint is over.” While technically this is true, let’s look a little deeper at the internal Scrum mechanics.

First of all, since testers receive user stories at the very end of a sprint, they are typically the ones who are under the time crunch to finish the user story on-time and with production-ready quality. However, if the entire team focuses on finishing the user story early, the testers may have more time to test it.

The “stop starting, start finishing” principle encourages better teamwork among team members. For example, in a standard Scrum team, I may choose not to help my colleague because I want to focus on finishing my own task. But if we are all focused on the greater goal of finishing the user story, then it’s in my best interest to help my colleague with his/her tasks. In fact, the primary measure of progress in a Scrum project (as per the Scrum burndown/burnup chart) is how much work remains in a sprint or how much work has been completed — NOT how much work has been started.

So in reality, the Lean approach of “stop starting, start finishing” also aligns very well with Scrum methodology. Specifically, it’s important to look at the user story as a whole during a Scrum standup and to identify how the entire team can work together to close the user story as early as possible.

In my own experience, the best way to do this is to discuss outstanding tasks during the standup and to place WIP limits with each workflow, like in a Kanban project. This approach will result in better throughput, a more thoroughly tested user story and — most importantly — a happier end user.

Shrikant Vashishtha is the Director of Engineering for GlobalLogic’s CTO department. He has over 15 years of experience in the IT industry and is currently based in Noida, India.