Yet another question during our Agile Webinar. This one on Total Unexpected Work.
Q: Question on Total Unexpected Work: Is that Metric for total work done in # of hours, and what is work?
A: Work can be classified as any tasks that you do. This could be understanding requirements, design, defect fixing, working on new features, and meetings. Each of these work types should be classified into buckets or categories that make sense for your organization. You don’t want to be too detailed because then data doesn’t accumulate into meaningful amounts.
Regarding measurement units, work can be measured in whatever measurement and estimating units your team uses – it could be story points, hours, business value, etc. However, we think you should be consistent. So if your velocity measurement is in stories, then you should use that. If you mostly focus on hours worked, then use that. The primary objective is to count work that is unexpected. Unexpected work can come from a number of sources including:
- Just a plain bad estimate. We all can do re-verifications and agile poker to get people to be honest, but sometimes we just make mistakes.
- Harder than we thought.
- Research took longer than we thought.
- Didn’t understand requirement.
- Requirement didn’t exist, or part didn’t exist, incomplete.
- We have more critical defects from the last sprint that need to get fixed.
This is just a small list. We all know that work just comes out of no where. Unfortunately, rarely are tasks easier than we thought :( and total unexpected work just keeps adding up. Sometimes we need to reset ourselves and even plan for unexpected work.