Hi all, I have a situation…
Team committed to the sprint goal during the sprint planning however at the end of the sprint, team completed only 50% of the sprint goal set . This has been happening from past 3 sprint cycles .
In Retro , team said they sometimes over commit and it’s challenging for them to predict the accuracy of commitment .
The features bleed into the following sprint and PO says team is moving too slow
As a SM what can I suggest to improve the process ?
So far have tried velocity based planning , capacity based planning , sprint goal commitment based planning
Please advice
Hmm – sounds like a bit to unpack.
Few things to think about, but there’s a lot of ground”
a) Sprint Goals
The Sprint Goal is a stepping stone towards the Product Goal; that’s usually an outcome rather than a bunch of functionality. Ideally it’s a measurable benefit for the users. There’s only one goal, not a check list. You can’t half do a goal – the benefit is obtained, or it isn’t. Scrum Guide is pretty good on this.
b) Sprint Planning
If you are using points, then I’d suggest plan for the mean number of points you have done, minus the standard deviation. Leave a buffer. You can always pull more work, but until that is happening consistently, you are taking on too much.
Be ruthless about splitting stories; the scope for errors, delays and rework is always higher on larger stories A couple of people swarming on the work for a day is a good size. One person for a week is not. Remember the INVEST criteria.
c) Daily Scrum
You are inspecting and adapting your plan to reach the Sprint Goal daily; maybe shift the stand-up to a “fist of five” vote on if the goal can be met. If you get less than a 4 or 5, then what is the team going to do, right now, to change that. That might include renegotiating some of the stories with the PO, or even rejecting them entirely. The Sprint Goal matters, not the PBIs.
Be ruthless on work-in-progress; stop starting new stuff and start finishing things. If it’s blocked, then swarm on the issue until it’s not.
d) Sprint Review
This is figuring out with the customers what will be next, to shape the upcoming Sprint Goal. Maybe incomplete stories/features are still relevant. Maybe they are not. They go back to the backlog, to be considered next time around.
e) Retrospective
Perhaps focus on what slows the team down for a retro?
You could run a sailboat, or do an Ishikawa fishbone to try and identify the biggest constraint.
You can support that by collecting data – cycle time, story count throughput per Sprint, velocity, average story size. What are the patterns telling you?
Hope that helps…