What's your definition of re-work percentage?

Question

After googling around for "re-work percentage", I'm struggling to find a consistent definition to compare with how our company defines re-work.

My understanding of re-work is:

For a given time frame, re-work = (# of stories that went back in to "In Progress" / total # of stories resolved)

Does the above formula make sense or am I missing another factor for the calculation of this metric?

Bill Sheboy · Answer

Connor, thanks for your detailed answers.  It seems you have lots of ideas to help measure, start team discussions, and take action to improve.

To me, re-work is waste due to an upstream process error.  And as you note, how this is measured is completely dependent upon how a specific team works.

Regarding my "oops" question, one way I found to address this is to account for time in status by measuring at a specific time-of-day (i.e. measurement granularity).  When an issue is accidentally moved to/from a step it is likely moved back quickly.  Jira does not do a great job of accounting for this idea, which is where automated adjustments, marketplace add-ons, or physical work boards help.

Best regards,

Bill

Connor Skiro · Answer

Hey @Bill Sheboy

Thank you for posing those questions, after giving these some thought here are my own opinions on re-work percentage:

1.  What is re-work? What problem are you trying to solve?

From a high level overview, re-work percentage is a lagging indicator that helps the team understand how often a feature or story is re-opened or transitions back into "In Progress" on a board, indicating unplanned time and effort and how we can mitigate these risks going forward.

2. What would you do differently if you had this information right now?

Again from a high-level, having this information indicates to the team that there is a disconnect from inception to deployment. I realize companies use different statuses, but here are some examples from previous experience:

* If the majority of features or stories transition from Product Acceptance to In Progress, that indicates to me requirements were vague or non-existent and we should review the team's Definition of Ready to ensure that the team is set up for success when delivering a feature or code to production.
* If the majority of stories transition from Code Review to In Progress, I might suggest the team pair program on the feature or take a Test Driven Development (TDD) approach to break down the requirement.

3. Is this a long-term measurement (metric) or something to solve a specific, short-term problem (a diagnostic)?  Why do you think that?

Realistically, you'd think this should be a short-term problem, but it's not. As teams change and as time goes on, I've noticed a cycle of high re-work percent > discuss in the next retrospective > create an action to review and update the Definition of Ready > the team follows the definition closely > re-work percentage decreases > the team becomes lax in requirements > re-work percentage increases > repeat.

Note: I do want to note for this question that thanks to automation, we have a rule that applies the team's Definition of Ready template to a story when it is created. This has vastly helped in ensuring requirements are clear.

4. How will you handle "oops" situations when an issue is accidentally transitioned backward/forward in flow?

This is a really good question and if I'm being honest, there isn't a good way to prevent this (at least that I could think of). However, I'd again like to note that thanks to automation, stories are now automatically transitioned based on git triggers. While this is no silver bullet to your question, it decreases the chance of user error.

I encourage others to participate and discuss differing opinions and views on this topic.

Best,

Connor

Bill Sheboy · Answer

Hi @Connor Skiro

To help the community give you suggestions, would you please describe:

* What problem are you trying to solve by measuring this information?
* What would you do differently if you had this information right now?
* Is this a long-term measurement (metric) or something to solve a specific, short-term problem (a diagnostic)?  Why do you think that?
* How will you handle "oops" situations when an issue is accidently transitioned backward/forward in flow?

Best regards,

Bill