Agile Thinking: Stop Starting Start Finishing
Kanban and Lean approach to developing products or services emphasize the importance of limiting "Work in Process" (WIP) items. When there are too many WIPs, it may appear that everyone is sufficiently busy but the end result is unsatisfactory.
The most important thing is to finish the user story - in other words, to stop starting and start finishing.
The "stop starting, start finishing" philosophy is usually associated with Lean and Kanban methodologies. After all, Scrum doesn't experience WIP issues, right? Wrong! Let's look at a typical Scrum standup.
This example scenario involves around nine to ten team members. The team creates subtasks for each user story together at the beginning of the sprint. By using this method, any team member can pick up any subtask at any point in time, thus reducing roadblocks and delays.
Limiting “Work in Process” (WIP) items is one of the key ideas behind Kanban and Lean approaches to rapidly developing product or service.
Team members share what they did yesterday, what they will do today, and if there are any obstacles during the Scrum standup. 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 complete the individual user stories and thereby the sprint. A better idea is to let the team decide how everyone can work together and help each other move each user story to the DONE column.
You might say, "That's an interesting theory, but is it really necessary? After all, the end user won't see the features until after the sprint is completed." While technically true, let's look a little deeper at how Scrum works internally.
For example ...
If the entire team concentrates on finishing the user story early, testers may have more time to test it so DEMO can be bulletproof for stakeholders.
The “stop starting, start finishing” principle promotes superior collaboration between team members. Take a standard Scrum team as an illustration: I could easily choose not to assist my colleague if I prefer to concentrate on accomplishing my individual task. In essence, though, if we make our main goal that of finishing the user story, it is to my own benefit to help with my colleague’s tasks. To reinforce this point, the core criterion for tracking progress in a Scrum project (according to the Scrum burndown/burnup chart) is how much work has been done or is left in a sprint – NOT how much has been started.
Thus, in reality, Scrum methodology is also aligned very well with Lean's "stop starting, start finishing" approach. During a Scrum standup, it's important to examine the user story as a whole and figure out how the entire team can work together to close it as quickly as possible.
In my own experience, the best way to do this, in a mature agile team, is to discuss outstanding tasks during the standup and place WIP limits with each workflow, as in a Kanban project. It will result in better throughput, a more thoroughly tested user story, and a happier end user.
Neno is a world-renowned hands-on Agile Coach and the originator of the term "Agile Habitat." He has worked with clients in the Far East, Oceania, and Europe on agile transformation initiatives. He is the founder of Agile Crew Academy & Business Agility CoE. Neno's work focuses on helping organizations adopt an agile mindset and culture so they can be more adaptive, responsive, and successful.