Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How do I create a bucket of effort for a sprint?

Eric Bailey
Contributor
September 7, 2023

Scenario:  Developers are working on Projects, but also are Production Support.  As such, they will need to be able to work on maintenance tickets.  We have decided they will have 60% project work and up to 30% maintenance.  

Issue:  We would like to have a "bucket" in each sprint for Maintenance Tasks.  Because these tasks may not be known at the beginning of the sprint (we never plan when our applications will break), we can't plan for the tasks themselves.  We would like to be able to account for the 30% in a generic "MX Work" bucket that the actual tasks can be added to.

Is there a way to do that in Jira?  Should we have parallel sprints, with one being the MX sprint working off the same backlog?  

The object is to not skew our reporting too much because we do plan for a portion of the sprint to be for maintenance.

1 answer

1 accepted

0 votes
Answer accepted
TC Wang
Community Champion
September 7, 2023

Hi @Eric Bailey Welcome to the community!

There are two possible ways I can think of. 

1) Create a separate sprint for MX Work ticket(s), without starting/closing that sprint. Once the MX Work ticket(s) is/are done, you can move it/them to the ongoing sprint and reflect it/them in your reporting. 

2) Or you can create another issue type dedicated to MX Work ticket(s). Assign 30% of your team's capacity (story points) to a single MX Work ticket in your ongoing sprint. If any maintenance task comes up, create a subtask under the MX Work ticket. For tasks that might exceed the 30% capacity, create subtasks in other MX Work tickets.    

Hope the above helps!

Eric Bailey
Contributor
September 8, 2023

Yes. That helps.  Those were two of the ways I was thinking about.  Someone suggested option 2 with the restraint that tickets are tied to that ticket via "Relates To".  That would allow them to estimate those tickets individually without affecting the points, as it will be indirectly using up the points.  

One thing we do have is existing maintenance tickets (stuff reported that has yet to be fixed).  For those, I suggested we have those estimated and control that 30% procedurally during planning, maybe leaving a bit of the MX allotment for urgent, immediatelly reported issues.

It is good to know that some of my ideas are not completely off base!

Thanks!

Like TC Wang likes this

Suggest an answer

Log in or Sign up to answer