Should I estimate repeating tasks (besides Stories and Bugs)?

Question

Besides User Stories and Bugs (no estimation) we have some repeating Tasks in our sprint, which have not much insecurity and a clear scope. For example such a task is "releasing our plugin" (building, uploading to the marketplace, writing docu and so on). We do not release every sprint!

For the sake of velocity one could think these Tasks should also have an Story Point estimation just like Stories have (which is no real estimation, as the time / complexity is known). Should we track Impediments in our Agile PM tool just like User Stories and Defects/Bugs? asks in a same way but I am not only thinking about impediments.

We have some more of these Tasks and I wonder what's a proper way to handle them?

Answer 1

"No invisible work, ever!" — CodeGnome's Law of Transparency

There are two common ways of dealing with recurring tasks in Scrum:

1. Having "evergreen" items for your Sprint Backlog, which the team can reuse but should eyeball for possible re-estimation during Sprint Planning and Sprint Retrospectives.
2. Rolling routine tasks into the Definition of Done (DoD), and ensuring the estimates made during Sprint Planning take the DoD into account when forecasting the level of effort for each backlog item.

There really isn't a "best" way to deal with it. It mostly comes down to whether the team considers the tasks separate work items that recur often—but not often enough to be a checklist item for the DoD—or whether the tasks are considered normal process overhead. As long as the work is clearly visible to the team and to stakeholders, you are on solid ground.

Answer 2

I don't think there is a right answer - it's mostly opinion, but I'll share a few reasons that I would choose not to estimate these:

1. It gets you nothing. Most of the benefit of estimating stories is the conversation that happens around estimation. Since these are repeated, clear items, you probably won't even have that conversation, so you aren't getting anything out of it.

2. It doesn't help with planning. Maybe your normal velocity is 30, but when you do a release in a sprint you only have room for 25. You already know that from past sprints, so padding out the sprint by slapping 5 points on the release item doesn't actually do anything for you.

3. It becomes problematic with long-term projections and burn-up charts. A lot of teams use the estimated story points in a release in burn-up charts to project feature completion, release dates, etc. Constantly adding other tasks to this pool is hard to account for. It's easier just to not include these (don't add story points) and just track actual stories delivered on your burn-up charts.

4. There's a better way. Like XP does with spikes, these tasks are often better handled with timeboxes. If your release usually takes 6-8 hours, timebox the work to that. Then if it reaches 8 hours without completing, the team regroups and looks at the situation to see what's going wrong. This often gives you a lot more value than story points for this kind of work.

The Scrum Police won't show up and yell at you if you estimate these backlog items and others may give you the opposite answer and have their own good reasons, but I hope this helps in your decision-making.

Answer 3

I will advice you to rethink by asking some fundamental questions: "why are you tracking?", "what's the value of tracking more?", and "who will use these numbers?". I wouldn't debate against you if tracking is a very core belief/practice of your organization as there's "no best answer" and it's up to one to subscribe.

I'm more of a #NoEstimates and constantly educate my teams to challenge whatever practices within the system, to eventually reduce as much as waste as possible (e.g. tracking itself can be seen as waste, not just the repeating tasks). Naturally, one would eventually ask: "why are we repeating these tasks, can we automate or eliminate them?"

Going back to your original question, "Should one estimate repeating tasks?" If your team highly rely on estimation for predictability and cost calculation, sure. If you see these tasks as value-add, you might want to incorporate them into your DoD as suggested by CodeGenome, having them seen as part of the stories rather than as separate tasks. I will also recommend continuously evaluating your current end-to-end process through value stream mapping, to consider the elimination and automation of some of these repeating tasks. Repeating without automation is really bad.

However, if these tasks aren't value-add and by tracking them won't make your teams profitable, your customers happier, and process leaner, then why are you tracking?

Answer 4

For velocity, I like to only estimate issues that give direct customer value. I can't think of a repeating task that provide direct customer value and if I could, I'd probably be on an operations team rather than a project team. Repeating tasks tend to be the cost of doing business, and they must be done no matter what. If you get really efficient at it, you'd notice a rise in your velocity because the team would have more time to do the work that delivers customer value.

I avoid even tracking repeating tasks as a story, task or bug and try to get those into DoD (for sprint, or release), or other checklists.

BTW, fixing bugs contributes to customer value, and we estimate that.