Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Self organizing team with technical difficulties
Last Post 12 Jun 2014 12:08 PM by Ian Mitchell. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
Stefano Marengo
New Member
New Member
Posts:1
Stefano Marengo

--
03 May 2014 11:42 PM
    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?
    Umair Iftikhar
    New Member
    New Member
    Posts:3
    Umair Iftikhar

    --
    04 May 2014 12:04 AM
    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.
    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    05 May 2014 11:47 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    09 May 2014 03: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.
    Nguyen Quang Vinh
    New Member
    New Member
    Posts:6
    Nguyen Quang Vinh

    --
    12 Jun 2014 11:44 AM

    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 ?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    12 Jun 2014 12:08 PM
    > 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.
    You are not authorized to post a reply.


    Feedback