Limiting “Work in Process” (WIP) items is one of key ideas of Kanban. A natural outcome of it, inherently coming from Lean philosophy is to stop starting and start finishing.
By having too many work in process items, it looks like everybody is busy but there is no functional outcome for the end user. So, instead, it’s important to work towards completing the user-story.
From the outset it looks like, “Stop starting, start finishing” philosophy is limited to Lean and Kanban world. Scrum world is either doing it well or doesn’t need it. Right?
Wrong!!!
Let’s take a look at a typical Scrum standup.
The context here is of a project in which there are around 9-10 members. At the beginning of the sprint, team does the subtasking of each user-story. The idea is – at any point of time, any team-member could pick up on any subtask and start working.
In a regular standup, every team member comes up with “What he did yesterday, what’s he going to do today and any impediments”. Everybody takes the turn and standup is over. Really?
Is that the only goal of a standup? Though everybody looks like working on individual tasks, do we get to know if we are completing a user-story? It’s really important to assess how as a team we could collaborate or help each other in moving a user-story out of the window.
You may say, “Hmm. Interesting but who cares as the end-user is going to put his hands on finished features only after the sprint gets over”. Looks okay on the surface but doesn’t sound right if we go a little deeper.
Testers in many Agile teams bear the brunt as they receive the user-stories for testing at the very end of sprint. If team focuses on how to finish user-story early collaboratively, it may reach in testers hands early and they have more time to test.
This principle also encourages team-work. For instance, as a developer, even though I know I could better help the other guy in finishing the work, I might not, as I am focused towards finishing MY OWN task. With this principle in place, as team is focused towards finishing the user-story, I may better come forward and help.
And yes, it has another parallel with Scrum as well. “The primary measure of progress” as per Scrum burndown/burnup chart is “how much remaining or how much completed and NOT how much started”.
So in a Scrum standup, it’s important to look at user-stories overall and see how to close them as early as possible. That could happen with a discussion as part of standup or by placing WIP limits with each workflow as it happens in Kanban.
Good comments Shrikant. Not going to get argument from me. I also think the concept of ‘Swarming’ where the team focus as much as possible on finishing each user story before moving to the next is certainly something that should be encouraged. The standup is a good medium, but also a good prioritised sprint backlog and a culture of swarming over each story to DONE, will ensure that the most important stories/features are built first and minimise the lots started not much finished 🙂
Thanks Mike for your comment. I particularly liked the phrase “culture of swarming over each user-story”. I think that’s the essential implementation pattern in Scrum world.
True. And maybe having the Daily Standups focus around UserStories than team-members might be worth trying out. In the DSUps, the updates are around User Stories in the WIP bucket.
Swarming is a nice idea, but we must keep in mind the Mythical Man Month. In other words, don’t think that if one developer could complete a user story in five days that five developers could complete it in one day.
Shrikant a wonderful principle which should be core to any agile team and very well written. I was a bit confused when you called out that team members sign up for sub tasks on a User story, following has been my observations on the teams I have worked with.
In my observation as a project manager an user story is always a stand alone, complete enough to cover an important piece of a large functionality, short enough to be completed by a dev pair or developer in not more than say 4-5 days. In the case of the estimate on a user story is beyond the max estimate sizing the existing story needs more analysis to be broken down into manageable scope and dependencies called out and spawned in to shorter stories if required.
I completely agree with you that it is important for the team to exactly know when would the story be done and that can only happen if in the stand up the Dev/Dev pair owning a story is being open and transparent of the challenges faced by him/her and also call out for help in form of swarming or Dev huddles to resolve issues related to design/integration/testing etc., as a Manager one should also be observant if the team members find the team safe enough to call out the challenges and not get blamed for the delays.
Thanks Vishal for your inputs. Somehow I sense a problem here. It looks like dev or dev pair owns the story. The reality should be – entire team owns the sprint backlog and stories. It’s the team success or failure together. As soon as individualism comes into picture, Agile model is doomed. Team should have a written or unwritten norm – “how can I help you?” and that should be for everybody to implement as part of standup. If that’s the mandated team culture, people will for sure open up to share issues and solve them together.
Subtasking to me is an important exercise. How about everybody know in every story what all needs to be done and also where you actually are? How about anybody could pickup any user-story at any point of time? How about getting design inputs from whole team instead of getting limited with individual decision or of a pair decision.
Hi Shrikant, you misunderstood me. When I say a Dev/Dev pair owns a story all I mean is accountability for the delivery of that particular story the Dev/pair signs up for and it is for him/her/them to make every possible effort to bring it to closure by escalating the challenges and providing the rest of the team with the exact status. The knowledge sharing can be achieved by pair rotations if your team pairs if not depending on the complexity and importance of the story you can choose to do selective pairing to keep the knowledge spread across. As far as owning the backlog is concerned I would abstract it to the point of saying the delivery of the project/product is and should be with the whole team immaterial of the role you play on the team.
The way I have seen it happen on Agile teams is everyone needs to be accountable for the success of the team because one can be the reason for failure of the team and hence accountability and ownership is a must for everyone on a Agile team, please lets not confuse ownership with individualism, I agree with you completely individualism dooms Agile teams and we should continuously strive to remove it if it exists in the team as it is an attitude.
On Subtasking, yes it is one of the most important part of development, when a developer picks up a story it is important for them to identify the tasks required to complete the story at the same time this exercise can also help to identify the real size of the story for estimation and it helps you to identify if you would need any tech tasks to be done prior to start working on the functionality and if it makes more sense to break the story further into 2 stories e.g a tech story for the tech platform and a story around functionality implementation.
Following is what we used to follow:
– Do a Pre-IPM analysis of the story with a dev on the team to subtask the story
– Revalidate if the story is small, independent and manageable and provide inputs to the BA/Product owner if you have one on the team.
– During the IPM, discuss the story with the entire team provide context share the subtasks identified to be validated by the entire dev team
– Do the estimation exercise
– PM will setup the velocity trend and the capacity on the team for the iteration
– Sign up for stories in the iteration based on priority and capacity
– On day 1 of the iteration the Devs sign up for stories, call for a Team/Dev huddle if they need more context either from the BAs or the tech lead or the entire Dev team
– In Stand-up update the progress on your story and when do you think you would be done, if it will spill over
– Everyday after the standup the team comes to the story wall and review the backlog and update status on the wall for there stories if they are done and want to move the story the next lane or want to rotate pairs or need to call a huddle etc.
(the above 2 steps hardly take 15 mins in total except if a huddle is required)
There are more details which I cannot cover in here but the overall idea is the team is functioning together and keeping everyone updated and calling for help when required while sharing knowledge and keeping the ownership and accountability to the team success intact. If everyone owns everything that at times is misinterpreted as everyone thinks some one else will be taking care of it :).
Hope I was able to explain.
That’s a great writeup on subtasking and its internals Vishal. Regarding ownership and accountability, I think we need to be a little careful. Though a pair volunteered to work on a story, team can still swarm to help in finishing story. Otherwise it may sound like, they are working on their story as they own it and I am working on mine. I need to more mindful in finishing mine.
I agree with you on the ownership and accountability getting confused and this is where a good manager/tech lead comes into picture who helps facilitate the conversations within the team and keeping the team together.