YDS: How Does a Scrum Team Handle Carryover Work?

Подписаться 24 тыс.

Просмотров 3,9 тыс.

50% 1

Today's question is all about carryover work. You know, the work that didn't quite get to DONE by the end of the Sprint. Listen in as Ryan and Todd talk about how a Product Owner can best handle carryover work to uphold empiricism and ensure that only valuable things are being worked on.
How does your team handle carryover work? Let us know in the comments!
This is one of those Scrum Master interview questions about Scrum that can throw you off. Do you understand why carryover work can add risk to your product development efforts? These Scrum Master day in the life questions can be tricky. Perhaps some Scrum Master training could help? Want to learn more about Scrum?
Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -
amzn.to/3fMpH5a
Join Ryan and Todd in a Professional Scrum Master course:
www.scrum.org/...
And make sure you subscribe to the channel!
DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!
FTC DISCLAIMER: This video is not sponsored by anyone.
Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.
#scrum #agile #professional scrum

Опубликовано:

5 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 24

@jameslloyd5359 3 года назад

I like it... there should be no work automatically carried over. It should be refined and reprioritised and hard questions asked: is the 80% enough? Is it still worth doing? Why did it take longer? Do we need to rephrase and adapt the work based on what we learnt during the sprint? The pattern I see teams struggle with is developers not really owning the fact that things are taking longer than expected... things can be "almost done" for 3 sprints, and that really makes stakeholders lose trust. This is probably reflected in the fact that sprint goals aren't being achieved (assuming the given PBIs are part of the goal - not always the case), but in teams that are still very focused on tickets it's a bigger problem.

@Geetu324 3 года назад

Thanks for the wonderful videos, they are very helpful. I have a question for you - What is the role Scrum Master can play in resolving dependency? There are situations when there is a lot of dependency on one person and it is affecting the overall progress of work. What can scrum master do to tackle this?

@claudiakommerell8318 4 месяца назад

I would additionally check if the PBI is probably obsolete/useless for the customer now that he has seen the increment.

@OlatejuOlanrewaju-zi8iv 3 года назад

Thanks Todd and Ryan for another beautiful one . Any suggestions on how to split larger scrum team that work as component teams into smaller teams ?

@MrAkkim 3 года назад

This is an episode I appreciate. But, I would still like to know what is the best way to handle work that is 80% completed in terms of effort. However, for whatever reason the work did not get completed in the current Sprint. Would you dump that 80% of effort back into to PB, and if yes is the answer, how would the Scrum teams effort be accounted for in the outgoing Sprint. How does the teams Velocity be accurately reflected for the subject sprint if the teams effort is not reflected. Though the User Story is not Done... Done, how do you handle this 80% of work???

@jocoign 3 года назад

Consider velocity just as a tool to make projection... projection for the developpers in sprint planning for a commitment that is challenging but not going too far (if it is breaking the sustainable pace... then the scrum team has to discut again on the How, What and probably be on the Why they will be doing this sprint) ... projection for the scrum team to give some information to a potential due date for a certain release version. You will take into account a bunch of past sprint to have the best idea of the effort that the developpers can deliver in one sprint, so it doesnt reality matter that the PBI point is counted in sprint X or sprint X+1. The question that should arise in sprint review, considering that PBI 20% undone is... What were/are the difficulties? is it still making sense to work on it? If it was part of the sprint goal it probably be making sense... but may be it was something not related to the sprint goal that the team achieved and this PBI was taken as something complementary... so is it making sense for the next sprint goal?

@MartydeLeij 3 года назад

Yes, definitely refine the leftover work and put it on the Product backlog before next Sprint Planning. Velocity consists only of Done pbi's, but if you think something like an "Effort spent" metric (maybe velocity + sp of pbi - sp of new estimation) could help you make better forecasts for the next sprint or beyond, why not just try it?

@MrAkkim 3 года назад

Thank you Jose and Marty for your feedback. To provide some additional context, the team I work with uses User Story points (Fib Seq). We assess an incomplete (caused by test environment or cross team dependency impediments etc.) story at the end of a sprint, by determining if the Users story was estimated correctly. If the team agrees the est. value is still accurate. Then as a team we determine how much work was completed based on the est. story value. So for example if a story is est. at 13 pts and 10 pts of work is deemed done for that story. Then a cloned story is created and reference to the original story with a remaining story pt value of 3. That way the teams effort for that story is reflected in the ending Sprint (I advised the team to use this method of accounting for work effort sparingly so that the practice does not become habitual). We deliver work incrementally, and the final product is released for consumption every 6 weeks or so. But, the overall idea is to ensure that the teams effort is accurately reflected through the teams sprint Velocity. We noticed that in the past if the team did not take steps to accurately report effort in such a case. So let's say the story which is est at 13 pts only have 3 pts of work left. But, was taken into the next sprint (Carry Over) as 13pts. The team would likely spend very little time to complete that story in the next sprint. So, let's say this new Sprint went extremely well. This one carry-over story with 13 pts.was not really 13 pts. But more like 10 pts thereby over representating the team velocity.

@lololima5533 3 года назад

As much as I love Agile,no practice is universal expect agile principles and scrum values. I was taking aback when you mentioned taking the metrics of "Planned vs Actual" is a motivation killer. I beg to difer. Thank you

@AgileforHumans 3 года назад

How does "planned vs actual" help us achieve our Sprint Goal?

@lololima5533 3 года назад

@ Agile for Humans In my environment, Actual vs Planned is key metric to measure the accomplishment of the sprint goal.We ask ourselves at end of each sprint,"did we meet the sprint goal"? 0% -100%?This has worked for years for us;we are motivated doing this. Should I now go ahead and publish as practice that must work in every environment? No.Agile is too fluid which makes being assertive on some issues difficult. I appreciate what guys are doing..awesome job!

@claudiakommerell8318 4 месяца назад

@@lololima5533 it would be great, if you learned during your sprint that a few sprint Backlog items are no longer needed and can be deleted. This would result in a bad score on plan vs actual, but it is great.

@osnyzinho 3 года назад

Hey Todd, still in this subject, if we are using scrum with Kanban, when an item needs to return to backlog, how should we control work item age?

@user-vk3xc8qs8n 2 года назад

Relating to past experiences until I get to start with a new team soon. In one organization, teams had chronic carryover. There were a lot of anti-patterns and Scrumbut that led to the carryover. It would make for a very long post. I did try to impact it although I was unsuccessful. If I had known about flow metrics, and the organization was open to utilizing Kanban with Scrum, I think the carryover discussion would have started to disappear where I was. The chronic carryover really eroded the trust of the Project Managers due to the lack of predictability of the work.

@AgileforHumans 2 года назад

The flow metrics can really help in situations like this. Good luck!

@haricharan6675 3 года назад

Hey Ryan, How to order Agile for humans swag, is it available yet ? Thanks.

@pawebaranowski8543 3 года назад

Hey Guys! You've done incredible good job. Thanks for your Vlogs Maybe we need a special episode.. Why people don't subscribe YDS chanel 😆😆😆

@g-ronnmendoza 3 года назад

What will your answer be to the customer if they gave you high level requirements and asks you when can you deliver it? Part of it is for them to know how much will they spend for it to be delivered by a certain date. Most will do Release Planning.

@krod16 2 года назад

What happens when you tell them when you can deliver it and they take it as commitment. And then you plan for 3-6 months, work on it, and it requires another 3-6 months. Will the customer be happy then? I think a useful tool seems to be the flow metrics and Monte Carlo simulation to give a probability number rather than a commitment.

@archiee1337 2 года назад

To reestimate or not to?

@Ella-dd3vz 3 года назад

when management wants to get a handle on "Predictability", the teams have no choice but to measure the "planned vs. actual" metric.... right?

@Rekettyelovag 3 года назад

Upper management wants this data because they have to decide which 3rd party dev team is the best. I bet they have an "order of effectiveness list" or something. So if there's important work they won't give it to X, but they want Y to do it even tho the PI planning is finished and Y is already overloaded. "We want this committed.". But I can think of another ordered list that contains velocity and this planned vs actual charts. This would help project leads and other celebs to decide which team or 3rd party company should be reduced in case of budget problem. Oh, also... the outcome of the PI planning is what the marketing uses to sell the upcoming version. OC the customers get angry if they don't get the promised features. I don't want to be negative, but there are companies operating this way...and our endless job is to make stuff better.