2

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?

2

"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.

  • Thanks for your Law, this how I understand doing tasks in a sprint :) One might say, the tasks are on the board, so they are not invisible 1) The "evergreen" items makes sense for tasks that occur every sprint? This is not the case, the tasks I am talking about comes every 3.-4. sprint. 2) As these tasks are not directly connected to a Story, I don't think they should be part of the DoD? The Tasks are neither real checklists, nor process overhead. They are needed to ship the product to all of our customers. – ppasler Jun 28 '17 at 4:44
  • @ppasler If you have tasks related to a release, either do them as part of a Release Sprint or do them every Sprint so things are always in a potentially-releasable state. The latter is the more canonical way, but your mileage may vary. – Todd A. Jacobs Jun 29 '17 at 19:47
3

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.

  • The point is, burn-up charts getting influenced by these tasks, that's why I thought about giving tasks SP values in the first place. This is needed to have a "kind of" evenly velocity. I want to keep the influence of these Tasks at a minimum. – ppasler Jun 27 '17 at 7:43
  • I'm not clear what you mean on burnup charts. If you are using longer-term burnups (like 3+ months out) then you would need to work every expected release task in if you estimate them or reach one would just bump up the target line. – Daniel Jun 27 '17 at 14:00
  • 2
    As for velocity, you don't have an even velocity. Every few sprints you can take on less feature development because you have to make time for these tasks. Your velocity is most valuable when you are showing how much progress you our making on building new product sprint to sprint, not how much work you do (this is the outcome vs output argument we so commonly hear in scrum) – Daniel Jun 27 '17 at 14:02
  • @ppasler Daniel's previous comment is right. Burn-up charts show "work done," which is largely irrelevant to a time-boxed framework like Scrum which is most effective when dealing with "work remaining." If you're reporting effort expended as a first-class metric, you've got a process problem. See Consumed Story Points for some related analysis. – Todd A. Jacobs Jun 29 '17 at 19:53
1

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?

  • Thanks for your thoughts! We use estimation and tracking for two things: 1) how much work might we get done in the future (p.e. next sprint)? 2) how much money might a User Story cost? I know that there is obviously no 100% certainty in our assumption, but we have some kind of magnitude. Also we have a special case where we do not release every sprint (although we have a mvp) and the task is not big enough to have a dedicated release sprint. I will have a deeper look into value streams, maybe this helps us. – ppasler Jul 1 '17 at 10:15
1

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.