6

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,121

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
  • 85,641
  • 18
  • 207
  • 307
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,420
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