I have commented in the past and will again. These short videos on aspects of Agile practices are some of the most useful continual training and reinforcement I have found. I love your approach and the insight. Thank you.
I like this video Mike... I am glad that you talked about bringing leaders along as well, which I see as part of the role of agile lead, okay, scrum master, but really, anyone in an agile leadership role. Outside pressure is always a factor, and can indeed become a catalyst for internal pressure which is not necessarily always a good thing, nor is it always a bad thing. A typical agile response to this is that it depends... As always, observe and learn... Thanks for the reminders - looking forward to your next video 👍🙂
Lately, my team has been getting a lot accomplished but at the same time, the rate of stories carrying over to the next sprint has increased. One of the reasons I believe why this is happening, is that they are not looking at the work as a team effort (we have a variety of sub-projects -- not one big over-arching project). I can't even count how often I have said that monitoring the stories they own on the storyboard is super important. Team members should use time during their daily scrum call updates to comment on any stories that could possibly carryover. As a team, we should be willing to reach out to the other team members to get help when needed. Other team members who are getting through all of their stories with no concern of under-delivering, can jump in and help those who believe they cannot get it done themselves. Other things that could be causing this, which we should learn from, is over-commitment and maybe under-estimating. Can you comment on this, Mike?
Hi Mary--it's great to hear from you. I hope you've been well since we met. I think you've summarized the problem and likely causes very well. If you're looking for advice on addressing this, I can suggest a couple of things. You may want to set a limit for how much work can be in progress (a _WIP Limit_). I'm guessing you have something like 6 devs and they'll have 6 stories in progress. 😥 If you set a WIP limit below the number of devs that will force more collaboration (i.e., at least will have to combine effort on one item). You may also want to start showing something like a "Carryover Report" each sprint review. It's just the number of stories unfinished at the end of each sprint. I don't really want to shame a team but if they left 5 stories unfinished, just put that on a report from sprint to sprint. They'll normally draw their own conclusions that it's not good to have that be more than 1-2. If you think the problem is underestimating, a good technique is called _unpacking._ In your next sprint planning meeting for items that you think may be estimated too low, ask the team members who will work on it to list the steps involved. These are tasks so they're already somewhat self-contained (small) but think about a coding task. You ask the dev what they'll do for that task. They might say, "Well, I'll think about the design a bit first as there are two ways I could do it. Then I'll write enough code to do this and that. Then I'll write some unit tests and that should be enough to hand off to a tester. Then I'll write the rest of it. Make any changes from bugs the tester finds and call it done." Explicitly listing steps like that has been shown to increase the estimate that person gives. So after unpacking the work, ask the person if they still think the coding task is whatever number of hours they said. Odds are they'll say, "Nah, it's probably a couple more than that." So note they unpack item A into A1, A2, A3... but then then have the chance to re-estimate A (not all the components). Another suggestion can be during sprint planning to assign primary and secondary people to tasks. The primary is what you already have. The secondary is someone who jumps in and helps as needed. I'd prefer to make those decisions in realtime based on who is available but in some cases doing it like this is needed for awhile. Also, consider dramatically reducing the work brought into the next sprint. Tell the team you want them to undercommit and feel what it is like to finish everything and, ideally, to add an item (rather than leave a few unfinished). When I do this I really push the amount low--I want to guarantee they finish, and this often makes some team members frustrated at how little they're bringing in. I reiterate they can add more. A basis for this is the work of Harvard prof Teresa Amabile who found that the biggest factor in job satisfaction is the frequency of small wins. (See her paper (or book) on The Progress Principle.) Good luck, Mary!
I encourage the team to target a more achievable goal in the next sprint. I want to break the habit of being close but missing. It's much more rewarding (and motivational) for a team to achieve a goal than to miss by a little. So aim for something more achievable. The team will make it and see how much better it feels. They'll then perform better and start to make more challenging goals. See the work on the "progress principle" by Teresa Amabile for more on this.
I have commented in the past and will again. These short videos on aspects of Agile practices are some of the most useful continual training and reinforcement I have found. I love your approach and the insight. Thank you.
Glad you like them!
How to distinguish a real master. A master can explain the whole point in 1 minute, while others will need more than an hour)))
I like this video Mike... I am glad that you talked about bringing leaders along as well, which I see as part of the role of agile lead, okay, scrum master, but really, anyone in an agile leadership role. Outside pressure is always a factor, and can indeed become a catalyst for internal pressure which is not necessarily always a good thing, nor is it always a bad thing. A typical agile response to this is that it depends... As always, observe and learn... Thanks for the reminders - looking forward to your next video 👍🙂
Thanks, Michael. I appreciate your comment.
@@MountainGoatSoftwareIt's my pleasure Mike 👍
Lately, my team has been getting a lot accomplished but at the same time, the rate of stories carrying over to the next sprint has increased. One of the reasons I believe why this is happening, is that they are not looking at the work as a team effort (we have a variety of sub-projects -- not one big over-arching project). I can't even count how often I have said that monitoring the stories they own on the storyboard is super important. Team members should use time during their daily scrum call updates to comment on any stories that could possibly carryover. As a team, we should be willing to reach out to the other team members to get help when needed. Other team members who are getting through all of their stories with no concern of under-delivering, can jump in and help those who believe they cannot get it done themselves. Other things that could be causing this, which we should learn from, is over-commitment and maybe under-estimating. Can you comment on this, Mike?
Hi Mary--it's great to hear from you. I hope you've been well since we met.
I think you've summarized the problem and likely causes very well. If you're looking for advice on addressing this, I can suggest a couple of things.
You may want to set a limit for how much work can be in progress (a _WIP Limit_). I'm guessing you have something like 6 devs and they'll have 6 stories in progress. 😥 If you set a WIP limit below the number of devs that will force more collaboration (i.e., at least will have to combine effort on one item).
You may also want to start showing something like a "Carryover Report" each sprint review. It's just the number of stories unfinished at the end of each sprint. I don't really want to shame a team but if they left 5 stories unfinished, just put that on a report from sprint to sprint. They'll normally draw their own conclusions that it's not good to have that be more than 1-2.
If you think the problem is underestimating, a good technique is called _unpacking._ In your next sprint planning meeting for items that you think may be estimated too low, ask the team members who will work on it to list the steps involved. These are tasks so they're already somewhat self-contained (small) but think about a coding task. You ask the dev what they'll do for that task. They might say, "Well, I'll think about the design a bit first as there are two ways I could do it. Then I'll write enough code to do this and that. Then I'll write some unit tests and that should be enough to hand off to a tester. Then I'll write the rest of it. Make any changes from bugs the tester finds and call it done."
Explicitly listing steps like that has been shown to increase the estimate that person gives. So after unpacking the work, ask the person if they still think the coding task is whatever number of hours they said. Odds are they'll say, "Nah, it's probably a couple more than that."
So note they unpack item A into A1, A2, A3... but then then have the chance to re-estimate A (not all the components).
Another suggestion can be during sprint planning to assign primary and secondary people to tasks. The primary is what you already have. The secondary is someone who jumps in and helps as needed. I'd prefer to make those decisions in realtime based on who is available but in some cases doing it like this is needed for awhile.
Also, consider dramatically reducing the work brought into the next sprint. Tell the team you want them to undercommit and feel what it is like to finish everything and, ideally, to add an item (rather than leave a few unfinished). When I do this I really push the amount low--I want to guarantee they finish, and this often makes some team members frustrated at how little they're bringing in. I reiterate they can add more. A basis for this is the work of Harvard prof Teresa Amabile who found that the biggest factor in job satisfaction is the frequency of small wins. (See her paper (or book) on The Progress Principle.)
Good luck, Mary!
How do you handle when a team almost achieves its sprint goals, but they usually miss them by an inch?
I encourage the team to target a more achievable goal in the next sprint. I want to break the habit of being close but missing. It's much more rewarding (and motivational) for a team to achieve a goal than to miss by a little. So aim for something more achievable. The team will make it and see how much better it feels. They'll then perform better and start to make more challenging goals. See the work on the "progress principle" by Teresa Amabile for more on this.