How can stretch or non-committed stories be denoted so that metrics are accurate?

Anita Palmer June 9, 2020

Not finding any info in Jira help on the term stretch or non-committed when running for an agile team.

1 answer

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 9, 2020

Hi @Anita Palmer 

To help the community answer, what problem are you trying to solve?

For agile teams, stretch work often is a smell of over committing, schedule pressure, or "irrational exuberance".

Instead of using stretch work, consider planning for the capacity the team believes they have, and refine enough additional work that more can be pulled when all planned is completed.

Best regards,

Bill

Anita Palmer June 10, 2020

Bill, thanks for the reply.   My 2 teams and I are new to the over all agile concept.  We plan for stretch to in the most part ensure that the team knows what the next possible work is within a sprint if something that was committee is unable to complete.  That said we have stories that by marking as stretch these are not negatively affecting our metrics.  Examples are:

a) a stakeholder external to our company has to provide the final approval to move to production

b) an internal team that we do work for, that unless the feature is a 'big deal' their acceptance of our work doesn't happen within our sprint even tho they had agreed to the timeline

c) provide a small list of stories to the team that if some of the committed stories are unable to be complete the team knows what to start on next.   I guess these could be left in the Backlog and added to sprint when needed instead of having them marked as Stretch

Our training was with SAFe Agile and we began with a spreadsheet to manage our PI Planning, Sprint Planning, and Daily meetings.  We are now asked  to use Jira with minimal training.  I have our current sprint loaded and active and am running in parallel  to get to our sprint end this Friday.  

I realize this reply is a bit long but appreciate your comments. 

     anita

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 10, 2020

Hi, and thanks for the explanation, Anita.

Sounds like a good idea to leave the additional "ready for build" work in the backlog until the team needs it.  It can always be pulled in later, and reduces the need to tweak the board filter to get the metrics adjusted.

I wondered about one more thing you noted: pulling additional work when the committed/planned work cannot be completed. Consider when this happens as an opportunity for the team to learn...what was the reason the work couldn't be completed and what could be done better next time?

  • Was there more to figure out with stakeholders before starting?
  • Was there coordination with other teams that was missed?
  • Were there quality issues causing rework?
  • Was it just too big to finish in the sprint?
  • And so on...

Any one of these is a chance for the team to learn and improve.

 

Best regards,

Bill

Anita Palmer June 10, 2020

We'll be doing our next sprint planning on Monday and i'll encourage the teams to not mark stretch and let the work be pulled in when needs to.  thanks for reinforcing that concept.   Re your questions:

  • Was there more to figure out with stakeholders before starting?    
    • not normally although i'm starting to see some of this
  • Was there coordination with other teams that was missed? 
    • no.  for internal teams the coordination is happening they just don't honor their commitment and we are working to start something to track to be able to share with those area's management.  for external stakeholder they respond as they respond on their own time--even when this work was important to their business.  We are all dealing with resource issues due to current environment!
  • Were there quality issues causing rework? 
    •  again, not normally
  • Was it just too big to finish in the sprint?  
    • sometimes and are working to break into better stories as we identify issue
  • And so on...

Any one of these is a chance for the team to learn and improve.

 

Best regards,

Bill

  Like

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 10, 2020

Thanks, Anita.  Sorry, I didn't mean those to be questions to you... just examples of things a team could discuss when expected work doesn't finish during the sprint.

__Bill

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events