Full team focusing on a single story VS small surgical teams working on different stories
Filed Under (from trenches) by mozammel on 07-04-2009
Tagged Under : team
It may be ideal to have your Scrum team focus on a single story first, complete it with compliance of their definition of done, and then move on to the next story, but in practice we are yet to achieve it. What we have found works best for us is we work like small surgical teams where one developer is assigned the chief responsibility of a surgeon for a story and another (or more) developer is tagged along with him as copilot/assistant. That copilot knows all the details about the work on progress and can act as an alter ego of the chief surgeon when she/he is not available. The situation may be reversed in some other story/module of the product where the previous copilot is playing the role of chief developer, and the previous chief is playing the role of a copilot.
Scrum synergies the chiefs of each story and also the copilots so that everyone is on the same page regarding the goal of a sprint, and overall product goal. When a conflict arises between two chief surgeons where one is needed as copilot for the other one, we fall back to the prioritized sprint backlog and complete the higher priority story first, then concentrate on the later ones even if it means leaving some stories undone.
Nice Post! Nice Pic too
. Great to see our experience documented so nicely
But I think in standard ‘Scrum’, the team tries to achieve the goals together. And the full team completes stories one by one. And the full team is responsible to complete the stories. In our case, we failed to follow the standard. The reason may be is our suspicion whether we’ll be able to complete all the stories within Sprint. But I think, we hadn’t tried enough to follow the standard and see what happens. Anyway, I hope we will be able to follow the standard in future Sprints.
@Mushfiq: Yes I agree that Scrum team aims to achieve the goals together, to be specific, Sprint Goal(s). They do whatever necessary to achieve the sprint goal. There is always a trade off between productivity and stability. Of course if we have full team focusing on single stories, we will produce much stable outcome from our stories, but overall productivity of the team may suffer at the very early stage of our product development. We will certainly consider it as we move from initial release to our engineering team to a more stable maintenance state.
I am not sure if you want the whole team to work on a single story at all. Can you explain the idea a little? I thought within the sprint, the team is supposed to deliver the sprint goals, however, they should be free to choose their tasks.
The team should first finish 1 user story that means that all the design, code & complete testing should be over & then they should pick up the next User story so that whole team is focused on achieving the goal together. But in reality what happens is that most of the teams start picking up parallel user story thinking that they would be able to do it faster but this way of working actually leads to Mini-waterfall within the sprint where Team will finish first the coding of the most/all the US & then start Testing.
The major impact of this is that majority of testing moves towards the end & there is little time left then to fix the faults ending up with the most of the User Stories getting descoped. So, in my opinion the Team should focus on One US at one time or at the maximum 2-3 User Stories.