![Stack of colorful rubber bands.](https://static.wixstatic.com/media/61f5d7_0738bf0aefbe4b39a21ea923e530afc0~mv2.jpg/v1/fill/w_980,h_980,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/61f5d7_0738bf0aefbe4b39a21ea923e530afc0~mv2.jpg)
A question that comes up regularly is whether Stretch Goals are good or bad. Stretch Goals are usually the result of a conversation in Sprint Planning. Someone suggests they should bring extra work into the Sprint in case they finish the work early. This practice sends a message that will only hurt the team in the long run.
Here’s why:
It becomes acceptable for the Developers to put pressure on themselves to get more done in a Sprint.
When the Developers achieve a “Stretch Goal,” it sends a message that it is OK to overcommit next time, too.
Product Owners and managers learn that extra work is “all right” and they expect it going forward.
Disappointment is had, by people on and off the team, when the work isn’t accomplished.
Leaders, POs, and others not doing the Sprint work, wonder why it wasn’t done.
Not finishing all of the work can give the impression that the Developers weren’t working hard enough.
In order to finish the Stretch Goal work, corners may be cut.
Completing Stretch work comes with a cost.
So what should Developers do if they finish their Sprint Backlog Items early? There are several ideas. The first one is to always check to see who else might need help. This includes the testing work.
If no one needs help, I suggest they keep a list of some very small "low-hanging fruit" items in the Product Backlog. I like to call these 'bonus work' items (not an official Scrum term). All team members are aware of these items and Developers know they can grab them if needed. This should only happen if the Developer(s) can get the item done in that Sprint. Developers shouldn't get complacent about carryover but that topic is for another newsletter. Bonus work is not the same as Stretch Goals because they don't imply that the Developers should push harder.
If no other team members need help and there isn't enough time to bring in a bonus work item, the team member can refine the Product Backlog, do some cross-training for others, or learn something new. Rarely is there ever anything that couldn't be done but if all options have been explored, there's nothing wrong with a Developer leaving early once in a while.
This is why I love Scrum so much, it puts people first. Always.
The Scrum Alliance has a new course for a skill that is in high demand: Facilitation.
It’s called Agile Coaching Skills - Certified Facilitator® or ACS-CF® and it provides training for anyone interested in developing their facilitators' toolkit. Facilitation is one of the many tools essential to coaching, and this course will equip you to build and hone the skill. Around the globe, there are less than 20 trainers approved to teach this class, and my partner, Judy, & I are two of them!
The Learning Objectives are:
Discover what a facilitator is and what they do
Practice the mindset of a neutral facilitator
Learn how to facilitate teams through conflict
Understand the needs of different teams
Apply the skillset before, during, and after a facilitation event
To learn more about it, click here. We'd love to see you there sometime! If you need to use up any training dollars before the end of the year, we'd love to have you!
Our full schedule can be found here!
Comments