Inconsistent Velocity

Why would a Scrum Master want to "make" a Scrum Team do something, and "restrict the amount of work" from a self organized Development Team?  Shouldn't the Development Team determine how much work they can take on in a Sprint?

Would taking a coaching and teaching stance be a better approach? Would teaching the Development Team to understand the concept that the entire Development Team is accountable for a "done" Increment?  Why are individuals estimating and owning Product Backlog items, rather than the entire Development Team as whole? 

Does your Scrum Team collaborate on a Sprint Goal in Sprint Planning?  If your Development Team forecasts too much, and learns more during the Sprint, what does the Scrum Guide say about this?

Does the Dev Team commit to a Sprint goal or to an amount of point ?

Developer has a Product Backlog Item (PBI) / Story which (s)he had estimated at the beginning to 13 story points and contained around 10 - 12 tasks. (S)He was not able to finish the PBI / story during the sprint (1 or 2 tasks out of 12 still in progress)

When did the Development Team first become aware that the story was unlikely to be completed, and why were they unable to collaborate in order to expedite it?

What do they think about the quality of the estimates they are all jointly accountable for?

Adding to comments above:

"then they are left with no work when reaching the end of sprint wasting capacity." - why would the team in such circumstances not just speak with the PO what else from the backlog could add to the increment, in the "spare" time?

In addition to what was added:

The Scrum Master has no right to restrict the Dev Team from doing anything. Take a look at the Scrum Guide again about the SM's service to the Dev Team. "Restricting" is not a term used, instead you see coaching and helping.

Based off your description, your team seems to be relatively new and have not reached the Norming or Performing stage of a team. They are unsure of how much can be done, the estimating is not being done as a team, and the developer you mentioned didn't seek or receive help from the rest of the team. How can a consistent velocity be expected in this scenario? Also, why is there such a huge emphasis on the velocity? Does your organization gauge a team's success by their velocity? Are you just wanting it to be consistent so you can say that your team is more consistent than other teams? Or are you wanting it consistent for the team's sake in order to better help them with planning?

Lastly, if your team selects items and complete them before the end of the sprint; there should always be something they can work on. Technical debt or look at the backlog to see if there is something they can add to the current sprint and knock out. There should never be a time where the team just sits and does no work for days at a time. That is when you come in again and coach them. 

Some suggestions:



- Avoid pulling in such big stories into the sprint and help the PO regarding this. I'm sure that story could be broken into 8 and 5, and you wouldn't lose total 13 points. Having said this, team's concentration should be towards the Sprint Goal, not gaining velocity points.



- When you realize that a story won't be completed, use "swarming" technique.



- Teach the development team that they don't own their own tasks, they own the Sprint Backlog as a whole.

Thank you for your responses. Perhaps I was unable to convey the issue properly.

Rephrased :

Developer has a Story which was estimated to 13 story points and contained around 10 - 12 tasks. Since team is collaborating on multiple small products (adding small features to each product), it picks up stories from the backlog as per priority and available capacity and a developer picks up a story and assigns to self, all the developers commit to their own set of stories (which in turn aggregate to the sprint goal). Now if the developer is unable to finish the story for any reason (maybe more than expected time spent on a task) and since we are near the end of the sprint where all members are busy completing their own work ruling out swarming, the story has to be moved to the backlog and then to the next sprint as leftover, burning a work deficit hole of 13 story points in the sprint. If this happens to a couple of developers then the velocity becomes too inconsistent. If the team pulls less work from the backlog skipping the bigger stories then they are left with no work when reaching the end of sprint thereby wasting capacity.

One solution that I could think of was to ask the team to break the story into smaller stories as suggested by @Ilter but there are times when a story just cannot be broken down further into meaningful parts.

Thanks Again..

@ Curtis : Yes, the team is new and I would say that we are in the storming phase. I am looking for consistency in order to help the team plan better and to bring some predictability in delivery so that the PO can plan an increment in a better way. And when I say no work at the end, it was not for the entire team just the developer.

Hope this explains in a better way.

That is a bit clearer. I dealt with a similar issue with the teams I have now. They were new to scrum when I came on board so we had plenty of times where we "bit off more than we could chew" so to speak. What I learned is that the best thing I could do was to remember the previous sprints and when the team started selecting bigger backlog items than they could complete; I raised the question "ok guys, it's your call but this looks like a similar item that we did a few weeks ago and couldn't finish. What is different that leads you to believe that we can get this done within the allotted time?" It's a question that makes them think it through. A few times the team realized it was not possible and instead we worked to break it down into smaller stories. Other times, they were able to complete a larger task because of things they had put into place in a previous sprint that would make completing this item much easier; and sometimes it was because the previous item was estimated incorrectly. Just remember to coach them by asking questions and let them decide what to do; even if it means having an inconsistent velocity for a while.

Now if the developer is unable to finish the story for any reason (maybe more than expected time spent on a task) and since we are near the end of the sprint where all members are busy completing their own work ruling out swarming, the story has to be moved to the backlog and then to the next sprint as leftover, burning a work deficit hole of 13 story points in the sprint.

I am curious about this comment though. While I understand each dev team member will decide to work on a story or part of a story, they still have realize that the team as a whole is responsible for completing the items selected in a sprint. So I guess I'm curious if the team is really being open with each other and seeking help when they need it. Are they calling out in the daily scrum that there is a chance they may not be able to complete something and need help? How soon in the Sprint is it known that there is a likely chance they will not complete the committed stories?

since we are near the end of the sprint where all members are busy completing their own work 

In my opinion, your issue Guarav is being exacerbated by the practice (apparently being enforced by you and the organization) that sprint work "belongs" to specific members of the Development Team.   This is simply anti-Scrum.

Per the Scrum Guide:

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Until you enforce team-based ownership of the sprint forecast, and until the team as a whole accepts responsibility for completing the sprint forecast, you will continue struggling with the issues cited in this thread.

Smaller stories are certainly a benefit to flow, and can help mitigate some of the pain you and your team are experiencing, but the root cause to me is the lack of team ownership of the work.

There is a simple solution to this problem. If the team is not sure about the estimation of work then they have to avoid such a big story. If the team is new, they have to pick up some small story lime 5,3,etc. according to Fibonacci series. So, there would be very little chance to move the entire unfinished story(13 sp) back into Product Backlog. 

If the team is not sure about the estimation of work then they have to avoid such a big story.

I respectfully disagree. If the Product Owner has an item that is the highest priority item to be worked on, the team should work with the PO and find a way to bring it into the sprint. Estimation is NOT the determining factor of bringing an item into a sprint. 

There is a simple solution to this problem. If the team is not sure about the estimation of work then they have to avoid such a big story

Are you sure it’s quite that simple? From the perspective of product ownership, would it allow value to be maximized?

Another suggestion would be to understand what predictability the team is after. You hear this a lot, outcome over output. Regardless of points completed per sprint, do you agree the team is always working on the right things? I would want a team that is predictably working on the most important work and getting feedback on what's been completed.

Then take it a step further to evaluate if the team using Sprint Goals correctly and/or the Sprint Length is appropriate.

1. Sprint Goal:
   • Are they committing to completing every Story in the Sprint? If they need to bring something in, are they committing to completing that story by the end of the Sprint, or else it likely won't get added to the current Sprint? If either of these questions are yes, then they have lost sight of the purpose of the Sprint and Scrum.
     
      
2. Sprint Length:
   • I recently have been mentoring the understanding of the Sprint not establishing a deadline but a checkpoint for feedback.
     • Are they finishing enough work that is ready for meaningful feedback?
     • Does team believe the large stories are well written and properly sized?
     • If splitting the story would make the value of the story confusing/lost, are they empowered to keep the story as-is? If they simply need another week and they can consistently have Increments ready to be demoed, give them that cause that's what Sprint success is.

For new teams, I give them a little grace. The Sprint is never 100% derived of Sprint Goal work.

New teams shoot for 70% to be captured in Sprint Goal, and the other 30% is still planned work but not a committed Sprint Goal. That 30% is still the most important next work to do. Maybe they finish, maybe they don't...but if the Sprint Goal has to expand, they know THAT work is more important than the 30%.

Over time, the %'s change and can get more aggressive to like 90%...but still, the commit is never to the Story completion/velocity/amount of leftover. It's to the goals of the team.

The goal for any team is to consistently be getting feedback for their completed Sprint Goals. That predictability is usually the behavior customers/management wants for their Scrum teams, even if they themselves don't know it yet!