5

Well in working with scrum it's always seen as important to make clearly defined stop and start points of small tasks.

However how do you capture "ongoing" tasks into a scrum system?

Like on friday after deployment we typically have "work on documentation and code review of old code to check for bad practices". This has no end, as constantly new code is found and new practices emerge; require updating of documentation and blaming old code to be updated. We're also too small of a company to make a separate system for these (devops and the likes are still tightly coupled to development). So to provide the manager of a time frame these things are calculated into the scrum work.

However how do you suggest to "mark" them - so that both management knows what happens, and we do not have constant backlogs of the same wording.

paul23
  • 1,061
  • 1
  • 8
  • 14

3 Answers3

10

I would suggest not making these "continuous ongoing tasks".

Rather than have generic "update documentation and review code for bad practices", define very specific work or tasks with clear objectives. Identify types of documentation that needs to be improved or specific problems with specific portions of the codebase. This will let you prioritize the updates of documentation or improvements to the code with other priorities for the product and give visibility into the costs and benefits of making particular changes.

If you aren't sure about what is necessary, you can consider using some of your refinement time to gain an understanding into what work needs to be done.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 1
    Well it's basically figuring out what is necessary as well keeping up to date with current technologies, and plotting out how they are relevant to us. "refinement time" is a non-liked term, management really really wants/needs to have this in more detail - in retrospect at least. (Like x hours researching probable toolset xyz, x hours working on updating documentation, x hours spent on reading paper abc). – paul23 Feb 03 '20 at 04:05
  • It seems like Thomas's answer would get you exactly what you say management is looking for. If you identified specific work items with clear objectives and tracked the time to do them, wouldn't that give you those hours numbers? – Daniel Feb 03 '20 at 06:21
  • @paul23 You tagged this question as [tag:scrum]. Scrum allocates approximately 10% of the Development Team's capacity for refinement in every Sprint. It could be more or less, but I usually suggest that spending less consistently is a red flag. If you don't have the time to perform refinement, that's a different problem and should be addressed since it's going to have a hugely detrimental impact to the team's ability to work. – Thomas Owens Feb 03 '20 at 10:49
1

In my experience, this often occurrs when doing scrum. As you have already discovered, monitoring progress becomes impossible and the tasks do not fit within the scrum framework.

Problem

Such continuous / ongoing tasks usually never end until the project ends. Hence, they cannot be planned into a sprint. You may be able to split some tasks into specific, well-defined tasks which are plannable. For some tasks, this may be impossible.

Recommendation

Ask yourself whether you want to plan the work for your ongoing tasks.

This depends on the amount of effort and required milestones (e.g. Have a document ready for review by some date). For work-intensive tasks, you should be specific and define the scope (e.g. "Review data model", "Update Architecture overview in the design document" etc.)

For tasks which are not work-intensive you may want to keep them as is without estimating any effort and add them to each sprint. This way, the task is not forgotten and at least discussed during your sprint planning and sprint review meetings.

helb
  • 1,380
  • 8
  • 14
1

It sounds like your ongoing tasks in this specific case can be considered paying-off your technical debt.

The default counter-measure of accumulating technical debt is usually improving your Definition of Done.

For example: If you have an ongoing task for writing documentation for your undocumented code, you might want to add "All code changes are documented" into your DoD.

If you struggle with fixing code-smells maybe you can use static code analyzers make sure the team adheres to common coding standards in your DoD. You can also add minimum required test-coverage, UAT, code-reviews, etc to the Definition of Done. Whatever the team thinks is necessary to prevent technical debt.

skahlert
  • 111
  • 1