1:41 I think it's called velocity, capacity is how much we can do based on hours at least in my team. I think this is one of the divergences we have. Story Points basically give the product owner/scrum master a way of broadly sizing the work. However, developers are different each with their own skill set. A task with a given story point say 5 may be claimed by developer A as maybe 9 hours **realistically** through a sprint while developer B may claim that should be 4 hours for him. At which case a developer may say I want tasks D,E,F which may have a large story point total, but he adds a "task" to implement it in 16 hours. Then they are subtracted from their sprint capacity. By the end of the sprint planning people should be within the capacity or very close to it. Capacity is defined as number of hours per day a person would work. This is typically 5 to 5.5 hours a day for employees, because people need to go to bathrooms and other business routine stuff like daily meetings, manager meetings, HR meetings, mentoring, learning etc. For contractors I usually bump it to 7 per day because we expect contractors to know the work and not paying them to learn. Now unless your team is specifically development only and you have no testers nor production users nor other teams to deal with (which is rare in my experience) you'd have to factor in a certain amount of time for things that would likely fall from the sky. We call that bucket "known unknown" which we use to fill up the capacity to 100% and know who to assign additional work to if needed.
I *almost* went with Velocity. I changed my mind at the last minute: a team that (a) knows its velocity and (b) usually uses it for Sprint Planning may (c) deviate from it for a particular Sprint - due holidays/absences for example. That's why I avoided Velocity. But the word "Capacity" - for the reasons you set out - wasn't a great choice.
@@Developmentthatpays The velocity can change over time and it averages out as well. It just helps the product owner decide how much of the product backlog to show to the development team during the sprint planning. However, it's not a limitter of work. Think of it more as how a limitter to conscious thought.
Actually minor correction, I took out the known unknown "time bucket" and leave some people to be under capacity. That saves us from doing one extra step. Those that are under capacity would just expect that stuff that falls from the sky can be put on their plate. However, we still have a perpetual work item called "Known Unknown" so we can dump tasks in there for trivial things that we don't want to go through the whole ritual of Bug / User Story.
Hey, Gary! First of all, many thanks for your episodes! They. Are. Great! :) But I have this question regarding both the Sprint Backlog and the Increment from the previous episode (with a DoD) and the ideal world I lack so much. Let's imagine a [common] situation: a Backlog item from the previous Sprint (Sprint 1) pops out with an unexpected bug. That item has already been checked, considered "Done", delivered and accepted in the previous Sprint. But now it requires a HotFix. Ex. You find out Tyler Durden has "contributed" to one of your previous episodes and you have to cut his "extras", re-edit, save, upload & publish the episode again :) How should you manage this kind of leftovers from finished Sprints different cases: 1) Previous Sprint 1 finished yesterday. Bug appeared today. And you have your new Sprint 2 planning meeting up ahead. Will the HotFix be placed in the upcoming Sprint 2 backlog by default? 2) What if the bug popped up when the Sprint 2 has already started and its backlog is locked? Should everyone wait till Sprint 3 for a Hotfix?
As we are talking about the developers’ control for sprint planning having a final say on the criterion. I wonder what your thoughts about possibly an old argument where management gets involved regarding refactoring code or changing configuration of some kind. The source of this idea stems from Stack Exchange here. softwareengineering.stackexchange.com/questions/387482/how-to-encourage-team-to-refactor/387485#387485
The product owner chooses which are the most important and brings them to the sprint planning meeting. The members of dev team bids on which ones would get done from the product backlog or state whether something is story pointed incorrectly AND may need to be broken apart. Every so often we give the flexibility of increaseing the sprint period by a week to handle really complex things that cannot be broken down easily but that needs to be agreed on. Though during holidays we usually increase it to factor in the days off that would occur thus impacting the overall capacity.
@@Developmentthatpays I find that every team is different, because people are different. What I disagree with is people going "you're doing scrum wrong" etc. and there's a proper way of doing things. I don't find Scrum to be a silver bullet but a guideline like the Bible. Everyone will interpret it differently and should really pick and choose the parts that work for them in the end because you're not selling your process you're building a product with a diverse group of people. Of course if there's a disgreement with an approach you'd still look at the scrum guides to see which one is correct and also factor in your team's situation. For example if your team doesn't really have the notion of stakeholders and mostly routine fixes and incremental improvements you may do more scrumban to avoid the heavy planning. If your team is small but has different skill sets you may forgo capacity planning etc. If your team has full time employees that because of reality cannot really spend 100% of their time on the project because reasons and your scrum master doesn't really have any teeth, you tweak things accordingly.
@Vincent Lord that's why we don't bother claiming it is Scrum we just call it "our process that is something based on Scrum" if we want the long form, but we still use the word Scrum because its easier and understood by the teams. :)
Hi, as a recent engineering graduate, I'm currently applying at a company who use scrum. Your videos are really insightful. Thank you!
Glad the videos were helpful. Good luck with your job application.
1:41 I think it's called velocity, capacity is how much we can do based on hours at least in my team. I think this is one of the divergences we have. Story Points basically give the product owner/scrum master a way of broadly sizing the work. However, developers are different each with their own skill set. A task with a given story point say 5 may be claimed by developer A as maybe 9 hours **realistically** through a sprint while developer B may claim that should be 4 hours for him.
At which case a developer may say I want tasks D,E,F which may have a large story point total, but he adds a "task" to implement it in 16 hours. Then they are subtracted from their sprint capacity. By the end of the sprint planning people should be within the capacity or very close to it.
Capacity is defined as number of hours per day a person would work. This is typically 5 to 5.5 hours a day for employees, because people need to go to bathrooms and other business routine stuff like daily meetings, manager meetings, HR meetings, mentoring, learning etc. For contractors I usually bump it to 7 per day because we expect contractors to know the work and not paying them to learn.
Now unless your team is specifically development only and you have no testers nor production users nor other teams to deal with (which is rare in my experience) you'd have to factor in a certain amount of time for things that would likely fall from the sky. We call that bucket "known unknown" which we use to fill up the capacity to 100% and know who to assign additional work to if needed.
I *almost* went with Velocity. I changed my mind at the last minute: a team that (a) knows its velocity and (b) usually uses it for Sprint Planning may (c) deviate from it for a particular Sprint - due holidays/absences for example. That's why I avoided Velocity. But the word "Capacity" - for the reasons you set out - wasn't a great choice.
@@Developmentthatpays The velocity can change over time and it averages out as well. It just helps the product owner decide how much of the product backlog to show to the development team during the sprint planning. However, it's not a limitter of work. Think of it more as how a limitter to conscious thought.
Actually minor correction, I took out the known unknown "time bucket" and leave some people to be under capacity. That saves us from doing one extra step. Those that are under capacity would just expect that stuff that falls from the sky can be put on their plate. However, we still have a perpetual work item called "Known Unknown" so we can dump tasks in there for trivial things that we don't want to go through the whole ritual of Bug / User Story.
Really good learning concept. Thanks for sharing!
Hey there, what an amazing set of videos. You are life saver...
Thank you!
Great video! Thank you.
Hey, Gary!
First of all, many thanks for your episodes! They. Are. Great! :)
But I have this question regarding both the Sprint Backlog and the Increment from the previous episode (with a DoD) and the ideal world I lack so much.
Let's imagine a [common] situation:
a Backlog item from the previous Sprint (Sprint 1) pops out with an unexpected bug.
That item has already been checked, considered "Done", delivered and accepted in the previous Sprint.
But now it requires a HotFix.
Ex. You find out Tyler Durden has "contributed" to one of your previous episodes and you have to cut his "extras", re-edit, save, upload & publish the episode again :)
How should you manage this kind of leftovers from finished Sprints different cases:
1) Previous Sprint 1 finished yesterday. Bug appeared today. And you have your new Sprint 2 planning meeting up ahead. Will the HotFix be placed in the upcoming Sprint 2 backlog by default?
2) What if the bug popped up when the Sprint 2 has already started and its backlog is locked? Should everyone wait till Sprint 3 for a Hotfix?
Thank you in advance!
Thanks a lot
You're welcome!
Good explanation
Thank you. Really glad you liked it.
As we are talking about the developers’ control for sprint planning having a final say on the criterion. I wonder what your thoughts about possibly an old argument where management gets involved regarding refactoring code or changing configuration of some kind. The source of this idea stems from Stack Exchange here. softwareengineering.stackexchange.com/questions/387482/how-to-encourage-team-to-refactor/387485#387485
Love that Stack Exchange piece. Really LOVE it. Beautifully written. Reminded me of something Uncle Bob says about a surgeon and hand-washing.
So ehhh, what if we finish the sprint backlog before the end of the sprint. Do we just get to go home?
Can we have a video on SAFe please
Trouble is, I don't have any experience of SAFe. Maybe I could do a "why I haven't done SAFe" video!
Uff So clear , very clear
is 30% of the sprint backlog is reserved for impedements? if the sprint backlog is full to the capacity. Then there is no room to add impediments
Good point.
Back with more Scrum-ness.
Would love to hear how*YOU* select items for the Sprint Backlog. Let me know!
The product owner chooses which are the most important and brings them to the sprint planning meeting.
The members of dev team bids on which ones would get done from the product backlog or state whether something is story pointed incorrectly AND may need to be broken apart.
Every so often we give the flexibility of increaseing the sprint period by a week to handle really complex things that cannot be broken down easily but that needs to be agreed on. Though during holidays we usually increase it to factor in the days off that would occur thus impacting the overall capacity.
Interested to learn that you extend the Sprint from time to time. I wonder how many teams do this. (A minority, I would have thought.)
@@Developmentthatpays I find that every team is different, because people are different. What I disagree with is people going "you're doing scrum wrong" etc. and there's a proper way of doing things. I don't find Scrum to be a silver bullet but a guideline like the Bible. Everyone will interpret it differently and should really pick and choose the parts that work for them in the end because you're not selling your process you're building a product with a diverse group of people.
Of course if there's a disgreement with an approach you'd still look at the scrum guides to see which one is correct and also factor in your team's situation.
For example if your team doesn't really have the notion of stakeholders and mostly routine fixes and incremental improvements you may do more scrumban to avoid the heavy planning.
If your team is small but has different skill sets you may forgo capacity planning etc.
If your team has full time employees that because of reality cannot really spend 100% of their time on the project because reasons and your scrum master doesn't really have any teeth, you tweak things accordingly.
@Vincent Lord that's why we don't bother claiming it is Scrum we just call it "our process that is something based on Scrum" if we want the long form, but we still use the word Scrum because its easier and understood by the teams. :)
Lol. You are amazing.
Thank you!