Sprint Carry Over
Is carry over between sprints by definition bad?
Even if your velocity is an acceptable level?
I suggested we assign our stories to the current Sprint and then add more bugs than we may be able to complete within the Sprint. My focus is to assign a manageable amount of stories as the priority and put a grab bag of bugs to complete as many as possible rather than waste time in meeting reaching consensus on what bugs to bring into to sprint.
I was told by the current scrum master this would mess up our numbers and make us look bad.
My focus is on productivity and progress, not posting numbers - especially if jumping through hoops to "post" "good" numbers decreases productivity and progress.
Any feedback is helpful.
Yes, that's bad. It's not about "posting good numbers", it's about setting the team up to succeed by creating achievable goals.
"My focus is on productivity and progress". Finishing the sprint commitment IS productive and that IS progress. If the team finishes early, THEN they can volunteer to take on more work (notice I said volunteer). There have been a few studies on this already, but in short, if you force more work on the team than they are willing to COMMIT to, they will produce LESS than if you hadn't.
If you want productivity and progress, then learn to LET THE TEAM DRIVE.
"rather than waste time in meeting reaching consensus on what bugs to bring into to sprint"... What is wasteful about the team understanding and being willing to agree to the sprint commitment?
Rule #1 - TRUST THE TEAM.
This might be worth your time to read: https://www.mountaingoatsoftware.com/articles/how-to-fail-with-agile
John,
I agree with your stance on numbers. Scrum metrics (like velocity) should be used as a guide to the team around potential future productivity, and as a forecasting tool for the business. I have had management ask me in the past to focus on increasing a team's velocity, and I turned around and then asked the team to double their estimates.
All jokes aside, there should be a healthy discipline within a team around limiting carryover. Often, a newer Scrum team views carryover items as "failures" - sometimes newer organizations have a similar view.
What is most important is that a team discusses and understands the reason for an item carrying over, and has a strategy in place to mitigate such an item from carrying over in the future. The goal is to reduce carryover to the point that a team has "clean" sprints. This builds trust between the product owner and the team, as the team delivers on their complete forecast. It is more difficult for a PO to plan future work/releases if there is uncertainty whether a team will successfully fulfill their forecast or meet their Sprint Goal.
The one thing I would caution against is asking the team to overload the sprint. Agile Principle #8 states that: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." A team simply cannot sustain a pace that optimizes them close to 100%. In fact, there are plenty of scientific studies that prove that slack built in actually improves flow, productivity, and flexibility.
Regarding your suggestion for teams to load up their sprint with bug stories in excess of their capacity, my thought is to leave the bug stories out of the sprint, prioritized at the top of the backlog, and then brought into the sprint as capacity and team preference dictates. This has a much higher probability for a clean sprint than the other method. You are concerned about the "meeting time" needed to reach consensus on which bugs to bring in, but how does that compare to the effort needed to manage incomplete bug stories at the end of a sprint?
This is a very good blog post by Mike Cohn on this subject:
https://www.mountaingoatsoftware.com/blog/unfinished-work-at-the-end-of…
> Is carry over between sprints by definition bad?
Are the team agreeing and achieving a clear Sprint Goal each and every Sprint? Is the work in the Sprint Backlog a coherent plan for meeting that Goal?
If so, can you clarify what exactly it is that is being "carried over"?
Hi @John.
Thank you for sharing this topic with us.
Sometimes I feel that Agile jargon creates waste and distraction from real problems. Scrum Guide 2016 does not reference familiar jargon like Story, Sizing, Velocity, and others. Some managers are driven by control and productivity gain and with less appreciation to the experimental nature of product development. If your specific context does not value experimentation or it is not-applicable, then managers will be concerned with Velocity management. This is rather than empowering the development team to decide what product backlog items it can complete in a Sprint to achieve its chosen Sprint Goal.
If your code has plenty of bugs then really you're not producing possible shippable increments. something is not right. Is it the quality of the developer? Not enough time for testing? Velocity set too high? Requirement changes allowed during sprint? Definition of done not well defined? Test data not correct? Test environment doesn't reflect reality? Plenty of things to look at.