My team never finishes all their stories in a sprint

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.

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.

> 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

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?

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.

> 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.

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.

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.

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.

So where is the Scrum Master in this situation? How come we only hear about Product Owner and Dev. Team?

> 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.

Sorry for digging out this old topic, but it fits quite well our current situation.

The dev team permanently over commits themselves, and also seems to don't give a damn, if they don't deliver what was promised before sprint start. The performance varies a lot and I cant explain whats going on. We have sprints of two weeks and already just plan with 50% of their time to develop. But even that isnt helping in delivering what they commited themselves, too.

I am a bit confused how this is going on.

I lack some real statistic reviews in Jira ... maybe some of you can recommend some good charts for finding the bottle necks and reasons for this situation.

Best,

Tom

It is possible to elicit user story and task burn-downs in Jira.

However, if I was you I would not go hunting for these charts immediately. It's more important for the Development Team to be able to account for its own progress using these or alternative measures.

Ask the team how they currently intend to provide transparency over their progress during the Sprint, whether it be Jira or something else. If they don't care, then that's the issue which you need to address first.

>> The dev team permanently over commits themselves, and also seems to don't give a damn, if they don't deliver what was promised before sprint start. 

Hi Tom - Does the Product Owner haver a vision for the Product, and does the team understand it and have they bought into it?

Are you using a Sprint Goal?  If so is the entire Scrum Team collaborating to come up with the Sprint Goal in Sprint Planning?  I have seen all too often Scrum Teams not using the Sprint Goal, and it can be powerful and be their North Star, giving them focus and accountability.

Have you thought of weaving in Scrum values into your Sprint Retrospective?  I have seen teams discuss where they think they are with each Scrum value, and it can surface a lot of discussions which may help generate conversations and some insights. 

You have an inexperienced Scrum Master maybe, but I am not sure. Like another poster said where are they in this picture? This is what they are far to coach and make sure everyone understand the framework.

I am going to start by asking in sprint planning are all stories fully understood? Are the stories written for a cross functional team? If you had a guess what’s the maturity level of Scrum? How do you estimate? Points? Ideal days? Ideal hours? Do they understand estimation and how it is important? What is the team dynamic meaning how long have they worked together, do they like each other, are there

conflicts? What does your definition of done say? Are they being distracted? If so by whom?

What steps are being taken to improve after your retrospective. What is coming out of the retrospective?

You said- “reliance on other resources outside the team or the customer”. Describe if you can because this can be a problem for sure.

Are you as the product power pushing to much and they are just trying to make you happy while in the end the sprints are failing. They should be working as Ian said as a self-organizing team that tells you we can take this much in based on the complexity of the stories you have asked them to do. It’s possible they just need to stand up and push back on you.

Are you adding work during the sprint thus changing the sprint goal?

Are they running into a lot of technical debt that is slowing them down?

Are they spending more time fixing bugs than actual work?

Who is keeping them focused? It should be the scrum master and the team themselves.

Do you see with just a little information how big of a list I can create to backtrack to a solution?

Ian is dead on everything he is saying, and I don’t always agree with Ian.

You are actually wrong here at least in scrum framework theory on who can be a member of the team. The person who trained you may have said that in jest because that is poopy.

None of the roles are part of the team you mention. There are 3 and they are listed in the scrum guide.

None of them contribute to the success of the increment as we all prescribe to. While I am the most lacks on Scrum principles and apply it in the way an organization wants within reason none of that statement is accurate. I think maybe the organization needs to circle back around on their view of the framework it sounds like it could be modified in such a way that what you think may be working really is not.

Can there still be a potentially shippable increment when few stories are not completed within the sprint?

Yes, of course. Isn't the whole purpose of writing code to have it deployed for the customers to use it? A product owner may choose not to release this potentially shippable increment, but that's another story.

I'm having the same issue here where completing all of the stories during a sprint isn't a priority (but suddenly it's important to Management so I'm trying to figure out how to make it work), but I also question the concept of a team that completes all stories in a sprint nearly 100% of the time.

While that's a great goal and all, if you load the sprints with the idea that the developers will be kept busy, it seems like you'd almost never complete every story in a sprint.  If the Developer did complete all of their stories, wouldn't they have to pull a story from the backlog and put it on the Sprint?  If they didn't, how do you track what they're doing and accomplishing in order to properly compute velocity?

Asked another way, do the developers walk into the Sprint meeting with nothing to do?  Did they JUST finish what they were doing right before the meeting?  If not, how can you NOT have unfinished work on a sprint?

Or are you saying that the INITIALLY planned stories are always completed?  If that's the case, do you schedule an extremely modest amount of work for the sprint, virtually guaranteeing that developers need to go to the backlog to fill out the remaining time?

Let's say our velocity floats around 17 points per sprint (yes, a completely arbitrary number) and I'm assigned two 8 point stories for the Sprint.  Those estimates better be nearly perfect or one entire story is going to fall off the far end of the sprint.

I'm not trying to be argumentative, but I am trying to understand this concept better and it's just not clicking.

 If they didn't, how do you track what they're doing and accomplishing in order to properly compute velocity?

I'm going to start with that statement and give you my opinion.  While velocity is important there are many ways to compute it.  You mention Story Points multiple times but that is only 1 way and it is based on a leading indicator. The measurement of completing stories is a trailing indicator.  My opinion is that you need both kinds of indicators to have any sound measure of velocity. 

I do not believe that a Sprint should be planned to keep the Development Team busy. I feel that a Sprint should be planned to deliver an agreed upon set of valuable functionality. If that can be done by the Development Team by working 6 hours a day instead of 8 there is no problem.  Scrum, and Agile, is not about being busy, it is about maximizing the value of what is delivered. 

I understand that most management is more concerned about people working 40 hours a week.  But that is one of the things that need to change when an organization adopts agile practices. Agile doesn't make you more efficient, it makes you more predictable. It allows you to deliver incremental value so that you can constantly "course correct" to arrive at the correct ultimate goal that provides the most value to the stakeholder. 

In agile, measurement of an individual shifts to the measurement of a team.  Individual contribution is less important than an individuals ability to raise the productivity and efficiency of a team. Teams should be measured based on the value that they deliver not the number of hours that they spend sitting at their desks writing code. There is a lot that a Development Team can do that provides value and doesn't involve writing code. How about refining Product Backlog Items before work begins. (Old days this was called research and design).  How about interacting with the actual stakeholders/users to better understand their needs? How about research into technologies so that they can ensure their solutions are the best for the stakeholder and prevents introduction of more technical debt?

I coach my teams to expect that over time some stories will not be done.  In my 30+ years of software development, I have very seldom been able to estimate(read guess) the actual work before I started doing it. You frequently uncover something you didn't know after you start doing the work. Sometimes that discovery will make it easier, sometimes it makes it more difficult.  Remember that in Scrum the Development Team is not committing to completing the Sprint Backlog.  They are forecasting that they can complete the work based on their knowledge at the time of forecast.  Anything discovered during the work is discussed daily at the Scrum and any impact to the Sprint is quickly communicated to the Product Owner so that contingencies can be managed.

Sorry to ask a random question here and this is based on the topic about scrum teams not 'completing' what was committed to.

What do you think about having random dev team members explain a story during refinement/planning to really access if everyone understands what that story is (after the PO has gone through the story/AC/Requirements and all)

(Back story: Having new team members who do not say much and can get assigned to any of these stories)

I have used that exact technique on more than one occasion. If during a refinement I witness a lot of discussion among the team about a story, I will politely step in.  I look at the person that has been the quietest and say something like "You have pretty quiet so I am assuming either you completely understand the story or are not clear. Will you tell us which one and then explain the story as you understand it?".  This will almost always lead to more discussion but with a common focus...explaining how each person agrees or disagrees with that individual's assessment.  I keep watching and will even repeat it if I feel it is needed.  I have also switched it with "You have been the most vocal so you must really understand this story. Can you explain it to me?".  

Sometimes during refinement it helps to refocus the conversation.  I have seen times where one of the team members will use my technique after seeing it in action multiple times.  I take that as a compliment because they apparently feel it has been useful and added it to their own bucket of tools.