Splitting the stories and points treatment to the overall velocity % during sprint planning

How do we fix this? 

What can change if you will stop using points and "capacity" in that way, and start to focus on delivering value and Sprint Goals?

We are in Sprint planning for Sprint 2 and loaded the stories based on our velocity points (say x). Now the capcity is shown as 105%, later after moving the spillovers to sprint 2 (that is 10 points), the capacity shoots up to 140%. While as scrum team we know the actual picture when the management/leadership looks in to it they are not happy to see the team cross beyond 100%

The purpose of a Sprint is to meet a Sprint Goal. Work that is not done for some reason can be re-estimated on the Product Backlog, but it does not spill over from one Sprint to the next.

In your situation, what are you actually using Sprints for?

The scenario that you have highlighted happens frequently, and yes - the team is not able to deliver all of the stories in the same sprint. One of the major causes - Scrum Team is being over ambitious, overlooking some of the fundamental issues that may occur.

Now, Sprint capacity will always depend on the number of team-members you have, it cannot shoot beyond 100% - this is just the new development capacity. It is always a good idea to reserve some capacity for variable scenarios (hot fixes, continuous improvements, etc). That way your team will have a conservative, yet valuable goal and will not come across too ambitious.

Secondly, it is very important to re-estimate and re-prioritise whatever was not completed in the first sprint, especially when it flows down to Sprint 3 or Sprint 4 for instance - because the value that it may have delivered may not be highest anymore, and this call needs to be taken post discussion with your Product Owner.

Regards,

Adwait.

One of the major causes - Scrum Team is being over ambitious, overlooking some of the fundamental issues that may occur.

It's important to plan a sprint based on empiricism. But don't forget to also look for other potential causes, such as:

• The items were not well enough refined;
• The items contained large amounts of work that didn't add enough value, and should have been descoped;
• The team aren't collaborating effectively;
• Sprint Backlog items are often sat waiting in an inactive state (e.g. Ready to be reviewed, ready to be tested, etc);
• The team didn't consider its progress towards the Sprint Goal throughout the Sprint, and adapt its plan in time to achieve it.

First, as previously said, you should be more focused on the goal than the metric: it is a tool, so the goal should not be the metric: the capacity. The point value might evolve, so the capacity might change (think of change of DOD, DOR etc...). But what is most important is the goal because if there is a problem, or the team feel they don't have the capacity, they should see with the PO what can be not taken but still be inline with goal. How can you achieve this without goal?



Second if you want an advice on capacity, the team each sprint shouldn't be loaded to the max, to help collaboration, small problems to cope with. If you really want a metric, no more than 80-90% of the real capacity. It can also help improve the quality.



Third, why at the beginning should the team be loaded at 100%? is it that the team is greedy or is it the PO pushing too much ?