Back when I used to work in IT Consulting, a common theme we observed was that deliverables within our Sprints were always extremely close (and often delivered upon the last day).
More often than not, this resulted in additional conflicts on the client site since the delivered Product Increment lacked certain functionality or simply failed during QA testing.
Luckily, we had an Agile Coach visiting us one day and introducing the client and team to so-called Stretch Objectives, which helped us tremendously in setting realistic expectations while keeping focus on the development work.
Definition
Stretch Objectives within a Sprint or Program Increment (PI) can be defined as tasks a team plans to do, but ultimately cannot commit to.
When estimating the needed effort during a Sprint, Stretch Objectives are excluded in our prediction.
Hence, they are somewhat of a nice-to-have, but ultimately don’t count against the Sprint’s success.
Benefits
Consequently, Stretch Objectives provide a multitude of benefits to Agile teams.
Greater commitment: By removing abundant tasks and making them a nice-to-have, teams can focus on the main priorities during a Sprint. Being able to deliver commitments is one of the most important aspects to increase team morale and build trust towards the team.
Flexibility: De-prioritizing tasks during a Sprint increases capacity for main tasks and thus allows the team to stay more flexible during an increment.
Improved Quality: If teams don’t incorporate Stretch Objectives, they must commit to deliver all of the tasks in a Sprint. Consequently, the team may have to trade off quality when stretched thin. This may cause tasks to not be completed and work to accumulate. By decreasing the amount of deliverables, the team can prioritize better and focus on delivering the fewer tasks.
While Stretch Objectives offer various benefits to Agile teams, certain aspects have to be kept in mind when implementing them.
Implementation
First and foremost, Agile teams have to validate the categorization of a tasks together with the Product Owner.
He or she obtains the knowledge to assess the value of a given task and how it is to be prioritized.
During a Sprint, Stretch Objectives should only make up 10 to 15 percent of the total work while the rest is committed to actual development work, documentation, ad-hoc requests and bug testing.
If Stretch Objectives make up the majority of your Sprints, re-assessing your categorization techniques is highly advised.
As I mentioned before, Stretch Objectives represent a nice-to-have during a Sprint. Therefore, they should not require too much effort to be completed.
Furthermore, finishing them not only increases the team morale, but increases trust from the organization (as they see a high performing team going above and beyond).
Nonetheless, don’t stress over too much in completing them and save some energy for the coming Sprints!
