YDS: What do you do with carry over work in Scrum?

No video

YDS: What do you do with carry over work in Scrum?

Рет қаралды 1,454

Күн бұрын

🚀 Elevate your experience! Join our channel for exclusive perks and videos:
/ @agileforhumans
🎬 Title: "YDS: Mastering Carry-Over Work"
👥 Pro Trainers: Ryan Ripley & Todd Miller
❓ Question: What's the Scrum strategy for carryover work?
🔍 Insights from the episode:
Two scenarios were discussed:
1. The carry-over was work not started - Return to the product backlog, refine if necessary, and compete in Sprint planning for the next Sprint.
2. The carry-over work was partially completed. It needs to be put in a good state, updated with progress and returned to the product backlog for Sprint planning.
🌟 Principle: Preserve Sprint and Product Goals-don't just stay busy, deliver value!
🔗 Join Ryan & Todd's Scrum.org course: buytickets.at/...
Explore more:
📖 "Unlocking Business Agility with Evidence-Based Management: Satisfy Customers and Improve Organizational Effectiveness" on Amazon -- amzn.to/4690qJy
📖 "Fixing Your Scrum: Practical Solutions to Common Scrum Problems" on Amazon -- amzn.to/46dAQTC
✅ Subscribe to this channel for Agile, Scrum, and Kanban insights: www.youtube.co...
🌐 Connect with Agile for Humans:
📘 Website - agileforhumans...
🐦 Twitter - / agileforhumans
🔗 LinkedIn - / agile-for-humans-llc
🔍 The Evidence-Based Company - theevidencebas...
📧 Email - ryan@agileforhumans.com
#agile #scrum #ebm #agileforhumans #scrummaster #scrumtraining #leadership #management #leadershipdevelopment

Пікірлер: 11

@shyamdangi2 8 ай бұрын

Great. It really cleared my basics. Thanks both of you for such a valuable discussion

@RecycleMeWild 9 ай бұрын

I discovered you guys a couple months ago when I was trying figure out how to help out my development team. Your content has helped me out tremendously! Thank you.

@neil1killick 9 ай бұрын

One thing I'd add - if there are unfinished PBIs at the end of a Sprint, this should trigger a conversation in the Retrospective about why this happened, and an improvement action to rectify it for the next Sprint. This is because PBIs are supposed to be refined before work starts on them such that they each represent no more than a few days of work. It could be because we only pulled the PBI in a couple of days before the end of Sprint (why did we do that?). Or it could be that we didn't slice the PBI before starting development on it (using capability, functional and technical patterns) to ensure it's only a few days of work, and thus we have taken on more scope for that item than we should have. Why didn't we do that? Or maybe we uncovered a bunch of unanticipated complexity. Why? Could that technical risk have been avoided with e.g. a spike? (or, again, slicing). Either way, it's an improvement opportunity. Typically, when faced with decisions like this, teams choose the easier option / path of least resistance (in this case simply continuing unfinished PBIs in the next Sprint without question). I'd say - as a rule of thumb - the easier option tends to be the wrong one - not only in terms of Scrum, but also more generally in terms of aligning to the principle of "Maximising value".

@AgileforHumans 9 ай бұрын

Thanks for the input @neil1killick! 💯agree

@sudakshinaghosh6342 3 ай бұрын

I need help. In my new team, some of the team members are non performing. Which results in load and stress with other performing members. Non performing members have been given training, knowledge handover, but still the same result . How to help them to improve ?

@dougslay96 8 ай бұрын

When a PBI that is not completed in a sprint and it goes back to the backlog, does the cycle time get reset when the PBI gets pulled into a future sprint?

@AgileforHumans 8 ай бұрын

Great question! I think it really depends on the context. If the PBI is immediately selected into the next Sprint and work continues on it, it probably makes sense to keep the original start and continue to count the cycle time. When mapped on a cycle time scatter plot this is some good retrospective fodder (how'd it take so long, can we break future work down better, etc.) If the PBI sits in the Product Backlog beyond that it probably makes sense to restart the clock. As you move away from that work it may/will change. Context is important though. Remember, we want our cycle time to be 'honest' and not just something that is cause for gaming. Management should NOT be pressuring to reduce cycle time or it will cease to give you any information.

@dougslay96 8 ай бұрын

Thanks for the response. You made a comment about Management should not be pushing to reduce cycle time. I thought that was an important metric that every team should be trying to manage. For instance, I have 3 teams where the estimated average cycle time is 13 days. Shouldn’t we be pushing to get that down maybe below 5?

@AgileforHumans 8 ай бұрын

A few comments: * The purpose of capturing cycle time is to use it for retro fodder (cycle time scatter plot for process improvement which may not always lead to a 'reduce it' conversation) and/or to use to for probabilistic forecasting (single item or multi-item forecasting using monte carlo). * I would not average cycle time ever. Averages are susceptible to extreme outliers. Cycle time is not to be captured for that purpose. * Comparing teams is not a good practice here either. * To go from 13 to 5 is no guarantee that you delivery more value. When using a metric like cycle time as a target for incentive (reward or punishment) bad behaviors will result. Those bad behaviors will likely result in the cycle time reducing by cutting quality or simply gaming the measure. The measure then loses it's purpose.