Self organizing team with technical difficulties
A self organizing team should have all the technical skills to release a done product increment.
What happens if they get stuck or if they have some difficulties knowing they should be self organizing and still (possibly?) produce a DONE increment? They have to solve it alone or they may ask someone (maybe form another team or a consultant) to come in help? Or should they try their best and end the sprint with a result which will probably not fulfill expectance by PO? Or talk directly with PO and put the story back in the backlog, which is not really in the scope of a cross functional team?
In a scenario where team is struggling to complete a story or two because they lack technical skills which are required for that story to be done, the team should bring this matter to PO who can make the decision.
This is highly unlikely scenario where the Sprint planning is concrete but it can occur due to complexities of system these days and teams unable to anticipate full technical details. In an ideal Sprint planning, the skills (technical or so) required to complete every single user story should be highlighted.
The potential action from PO for this scenario will be,
i) To put the story back in backlog for next Sprint
ii) Get outside help to resolve the issue if it does not compromise other team(s) output [usually this is avoided by nominating another member of team with the required skill set as shared resource during Sprint planning - e.g. a designer, a System Architecture etc]
PO supports the team and do what is necessary to make sure all stories are in DONE state.
What happens if they get stuck
The following should be done
1) Raise an impediment with the scrum master as soon as possible
2) Leave it to the scrum master and product owner to decide how best to tackle this situation
3) Learn from the experience and have a more rigorous sprint planning in future to make sure there are no surprises
This will make sure we have taken steps to remove to the impediment and learnt from our experience.
> They have to solve it alone or they may ask someone (maybe form another team or a consultant) to come in help?
A self-organizing team should have all of the skills and resources needed to meet the Definition of Done for each item they have accepted into their Sprint Backlog. Should they subsequently encounter an impediment, they are within their rights to try and secure any necessary people, tools, or materials which they do not currently possess so that the Sprint Goal can be met. It is the duty of the Scrum Master to assist in this matter and to ensure that the problem is subjected to the appropriate level of retrospective scrutiny, so that the risk of recurrence is minimized.
> Or should they try their best and end the sprint with a result which will probably not fulfill expectance by PO?
No, that isn't an option, because it implies that the PO is not being informed of developments in a timely manner. He or she would not then be in a position to appraise stakeholders accordingly, and the updating of release forecasts and the Product Backlog would be put in delay. Instead, the team should inform the PO as soon as the outcome of the Sprint is in reasonable doubt, so that expectations and priorities can be revised.
> Or talk directly with PO and put the story back in the backlog, which is not really in the scope of a cross functional team?
Yes, in so far as direct communication between Scrum Team members should always be encouraged. However it is up to the PO to decide whether or not the story can be remain undone without placing the value of the increment, as expressed by the Sprint Goal, in jeopardy. The whole team should replan as necessary to ensure that the Sprint Goal can be met. It is certainly within the remit of a Scrum Team to do so.
Posted By Ian Mitchell on 09 May 2014 08:56 AM
> They have to solve it alone or they may ask someone (maybe form another team or a consultant) to come in help?
A self-organizing team should have all of the skills and resources needed to meet the Definition of Done for each item they have accepted into their Sprint Backlog. Should they subsequently encounter an impediment, they are within their rights to try and secure any necessary people, tools, or materials which they do not currently possess so that the Sprint Goal can be met. It is the duty of the Scrum Master to assist in this matter and to ensure that the problem is subjected to the appropriate level of retrospective scrutiny, so that the risk of recurrence is minimized.
> Or should they try their best and end the sprint with a result which will probably not fulfill expectance by PO?
No, that isn't an option, because it implies that the PO is not being informed of developments in a timely manner. He or she would not then be in a position to appraise stakeholders accordingly, and the updating of release forecasts and the Product Backlog would be put in delay. Instead, the team should inform the PO as soon as the outcome of the Sprint is in reasonable doubt, so that expectations and priorities can be revised.
> Or talk directly with PO and put the story back in the backlog, which is not really in the scope of a cross functional team?
Yes, in so far as direct communication between Scrum Team members should always be encouraged. However it is up to the PO to decide whether or not the story can be remain undone without placing the value of the increment, as expressed by the Sprint Goal, in jeopardy. The whole team should replan as necessary to ensure that the Sprint Goal can be met. It is certainly within the remit of a Scrum Team to do so.
Hi Lan,
You mean that there are 2 steps to do in this case :
1st step : Talk directly with PO to negotiate for the scope of the work that out of a team's ability. This is for short term solution
2nd step : Raise the issue in the retrospective meeting so that team have necessary people, tools, or materials for upcoming sprints ? Long term solution ?
So in case there is only once option can be selected what we have to choose ?
we have to choose 1st step as the work around right ?
> So in case there is only once option can be selected what we have to choose ?
In Scrum that would be a false choice. A team has to be able to replan in order to meet a Sprint Goal, and the team also has to be able to inspect and adapt its implementation of Scrum in order to improve it.
It's not unreasonable to say that one is a short term fix while the other is longer term. However both capabilities are essential.