Forums

By posting to our forums you are agreeing to the Forum terms of use.
My team never finishes all their stories in a sprint
Last Post 06 Sep 2013 06:00 PM by Robert du Toit. 11 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Robert du Toit
New Member
New Member
Posts:38
Robert du Toit

--
03 Sep 2013 08:32 PM
    I am looking for some community feedback on what I have observed from working with 3 separate scrum teams over the last year: we rarely (if ever) finish all the stories that the team commits to during a sprint. We have, however, been able to achieve decent (and sometimes surprisingly consistent) velocity.

    I am the Product Owner, so I should be interested in business value output. However, I am also interested in consistent output so that my stakeholders (customers) expectations are met.

    During sprint planning, should I:
    - Play it as it lays (let the team decide on number of stories without my input)
    - Push for more stories to be included (drive the team towards a more ambitious goal)
    - Push for less stories to be included (be more assured that stories committed to will be included)

    I feel like if I push for less stories to be more sure they will be completed, they still won't be completed and less work will be done. But it's unsettling that the team cannot complete what they commit to, and I question the commitment of the team. On the other hand, progress can be stalled by reliance on other resources outside the team or the customer, so maybe some incomplete stories are inevitable.

    It seems like it may be an application of Parkinson's Law, where the time spent expands to fill the time available: http://en.wikipedia.org/wiki/Parkinson%27s_law

    Have other POs encountered this problem?
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    03 Sep 2013 10:11 PM
    You use the word "push" a number of times. Pushed teams may well feel pressured into overcommitting. What about pull though? As Product Owner, are you collaborating with the team and exerting pull evenly throughout the Sprint?

    From what you describe, there doesn't seem to be much of that collaboration going on between you and the team during each Sprint.

    It could also be the case that the team don't own their process, and cannot complete some requirements due to external dependencies, as you suspect. Again, better collaboration should make this apparent.
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    03 Sep 2013 10:57 PM
    Good point about "push" Ian. Isn't it my job as PO to push for as much business value as possible for each sprint? I guess this is my question; I'm not sure I'm pushing enough in negotiation as to what goes into the sprint. It's possible I'm pushing too much and that's why we don't complete all the stories but I fear that we will complete even less if I encourage them to take on less in order to ensure we complete everything each sprint. That's the balance I'm trying to find.

    I am also (as Business Analyst) a member of the team, so I am also careful to say at each sprint, "are we sure we can complete all of this functionality this sprint". This is another concern of mine - can I be PO and a member of the team at the same time? Should I have another BA be the team member while I focus on PO or can I be both (as seems more efficient)?.

    What do you mean by exerting pull? We now have a story burndown as part of our physical task board, I think it is helping.

    Our collaboration (according to retrospectives) has been good. How can I expose reasons for incomplete stories beyond what we discuss in the retrospective. I mean, that provides an excuse, but is it normal to not complete all stories on a consistent basis?

    Thanks for your response.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    04 Sep 2013 03:34 AM
    > Isn't it my job as PO to push for as much business value as possible for each sprint?

    Frankly no. Your job as PO to *pull* for as much business value as possible for each sprint (see later).

    > can I be PO and a member of the team at the same time?

    As PO you are by definition a member of the Scrum Team. You can also be a member of the Development Team, but only if you are actively working on the completion of work along with the other developers. Remember that the Development Team does not recognize any skill silos.

    > Should I have another BA be the team member while I focus on PO or can I be both (as seems more efficient)?

    A PO should be able to communicate product requirements to the Development Team, and to that extent a PO may subsume a business analysis function. If you wish to delegate analysis to a BA then that is your prerogative, but you as PO will remain responsible for the Product Backlog and for liaison with the developers. That responsibility cannot be delegated.

    Note that a BA cannot be a member of either the Development Team nor the Scrum Team at large, since BA is not one of the three Scrum roles.

    > What do you mean by exerting pull?

    Pull is a consistent and even demand for work. You, as PO, are responsible for the product and as such you will need to evaluate all deliverables. You can then account for them and potentially release a meaningful increment into live.

    That is work that you need to do, but you can't do it until the developers supply you with deliverables that they believe meets the acceptance criteria and the Definition of Done. So you need to collaborate with the developers all the way through the sprint, explaining the requirements and exerting a demand for completed stories that you can evaluate. You don't want all of the risk, and all of this evaluation work, left to the end of a sprint. You don't want any nasty surprises in a demo session or review. So you should collaborate with the developers continually, trying to get an even burndown of completed work during the sprint that you can examine. That's pull.

    > is it normal to not complete all stories on a consistent basis?

    It's certainly not normal in a good Scrum implementation. This problem can happen if teams are:
    - overestimating their capacity (perhaps due to pressure)
    - underestimating the amount of waste they incur (unplanned work)
    - have dependencies on others outside the team, and cannot complete work due to associated blockages
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    04 Sep 2013 06:01 PM
    Thanks again for the feedback, Ian!

    >> Isn't it my job as PO to push for as much business value as possible for each sprint?

    > Frankly no. Your job as PO to *pull* for as much business value as possible for each sprint (see later).

    Hm, I think I get the distinction. The concern is that the team will over-commit during planning... so I should be passive there, but encourage output from what the team has committed to once the sprint commences.

    ... agreed ...

    > Note that a BA cannot be a member of either the Development Team nor the Scrum Team at large, since BA is not one of the three Scrum roles.

    So I get this in theory, but in practice we have QAs who can't code, and BAs who can't code, but are still contributors to the development team. Surely you're not saying they should be omitted from the team?

    > So you should collaborate with the developers continually, trying to get an even burndown of completed work during the sprint that you can examine. That's pull.

    Thanks for the explanation. Hopefully I got it as explained above. One thing our current team has decided to do is to work on complex/larger stories early in the sprint which leads to delayed delivery of stories for testing which is contrary to an even burndown but we are going to run with that until we see it lead to bottlenecks.

    >> is it normal to not complete all stories on a consistent basis?

    >It's certainly not normal in a good Scrum implementation. This problem can happen if teams are:
    >- overestimating their capacity (perhaps due to pressure)
    >- underestimating the amount of waste they incur (unplanned work)
    >- have dependencies on others outside the team, and cannot complete work due to associated blockages

    Reviewing a few retrospectives from my last team, I see a lot of the third (dependencies) as impediments. So maybe this is an organizational problem as opposed to a team problem. We are dependent on our customer, other departments, and have production support issues that all have an impact.

    I still feel wary of Parkinson's Law. But I would probably trade for consistent velocity and completion of all stories over slightly faster but more variable velocity and incomplete stories.

    You actually have personal experience with teams that consistently complete all their stories each sprint? What % of the time?
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    04 Sep 2013 09:28 PM

    Note that a BA cannot be a member of either the Development Team nor the Scrum Team at large, since BA is not one of the three Scrum roles.


    Completely untrue. Everyone needed to produce the product including the person ordering lunch for the other folks should the team choose to have that skill on their team is part of the Development Team. BA's can very much be part of the team. As can testers who don't code, technical writers, designers, marketing folks, lawyers, pricing specialists, mathematicians, and any other title that reflects a skill needed by the Development Team to keep things moving.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    04 Sep 2013 11:55 PM
    > in practice we have QAs who can't code,
    > and BAs who can't code, but are still
    > contributors to the development team.
    > Surely you're not saying they should be
    > omitted from the team? 

    I'm saying that if they are on the Development Team they can't be BA's or QA's. Scrum does not recognise these specialisations or skill silos. It may take time to get a cross functional team, but the first step is to eliminate the idea that only certain kinds of developers are meant or allowed to do certain things.

    > You actually have personal experience with
    > teams that consistently complete all their
    > stories each sprint?

    Yes, it isn't a myth.

    > What % of the time?

    A mature team that owns its process can be expected to do this practically 100% of the time. However, only a very small portion of teams are at that level - not even 5% in my experience. Implementing Scrum is hard.
    Fredrik Vestin
    New Member
    New Member
    Posts:61
    Fredrik Vestin

    --
    05 Sep 2013 01:32 PM
    I would be concerned if a team always managed to complete all stories in the sprint. Are they playing it safe because of fear of failing? Are they experimenting and being creative? Unless you have a situation where you have very well-known requirements, all the technology is known I would not expect this to be the norm. I also dislike the notion that not finishing all stories is failure. It is what it is.
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    05 Sep 2013 03:10 PM
    I would be concerned if a team always managed to complete all stories in the sprint. Are they playing it safe because of fear of failing? Are they experimenting and being creative?


    +1 - Scrum is for the complex and creative. Shake it up.
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    05 Sep 2013 06:10 PM
    Thanks, folks, for the additional feedback. I feel a bit better. Our reality is one of blockages by things out of our control, and non-predictable impediments such as production problems. I can manage stakeholder expectations knowing this reality.

    I guess what I will try to do is better articulate the Sprint Goal. This way we can have a way to say "this sprint was a success" without having to finish ALL of the things each sprint.

    About the titles/skill silos, I think I get what you are saying, Ian. It's not that BA/QA etc. can't be on the team, but that if they're in the team their perceived title should be developer, just like the rest of the team.
    Joshua Partogi
    Posts:99
    Joshua Partogi

    --
    06 Sep 2013 09:45 AM
    So where is the Scrum Master in this situation? How come we only hear about Product Owner and Dev. Team?
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    06 Sep 2013 06:00 PM
    > So where is the Scrum Master in this situation?

    Well, that is a good question. Where should he be?

    He is encouraging the team to challenge themselves, while reminding them that the sprint backlog is a commitment to complete the stories.

    During the sprint he is updating the burndown chart and making the team aware of how much time is remaining in the sprint, and how many stories are yet to be completed.
    You are not authorized to post a reply.


    Feedback