What to do with work that seems too small to bother planning?

Question

We are a team whose main work is technical but not software development, and we have been using Scrum as our main framework for a while (although it's likely that what we're doing is closer to ScrumBut in various ways).

With that said, we had a question come up in Sprint Planning today that I didn't know the answer to - sometimes, when planning out work, there is a temptation to just do some of the tasks without including them in the Sprint Backlog. Either they're small enough that it's quicker to just get them done rather than creating a Jira task, or the task is part of the planning process (e.g. doing a quick bit of research to help understand something that needs estimation) but doing it leads naturally into larger work.

Is there any guidance on recognising when something needs to be put on the board rather than just knocked over on the side? The best I could suggest was "If you need to think about it, you probably need to put it on the board".

Answer 1

Tasks that are not listed increase context switching. People have to keep them in mind, but they forget. Then they remember about them in the middle of another task and think to themselves "Oops, I almost forgot, but I need to keep it in mind. What else did I forget?". This draws brain power away from the actual task at hand. All this may repeat multiple times, and by the end of the day you feel exhausted because you frequently switch to thinking about these small tasks.

It's just easier to create a ticket for each such task. Or create 1 ticket where you list all the small tasks as bullets. After someone implements one of the small tasks he/she can simply edit the text and put a small check mark next to the finished items.

Whether you ignore it during planning doesn't matter that much. If you estimate during your planning - just quickly put a small number in the field and keep going.

Answer 2

There are two separate but related questions here.

---

How do I account for work that is part of the planning process?

Scrum accounts for this in Product Backlog Refinement. The teams that I work with tend to not have issues in Jira for refinement work unless the work is going to be intensive. Time is allocated every Sprint for individuals or small groups to look at the work at the top of the backlog and start to add details. Labels allow the team to filter on issues that need refinement or particular attention (development, UX, product).

For very intensive work that produces something other than updates to a Jira ticket, that may be called a Spike, which would be tracked as a Jira issue, assigned to one or more people, and the output attached and reviewed.

---

How do I manage small tasks?

During refinement, the person or group working on refining a particular issue may start to add tasks. Rather than using subtasks or separate issues in Jira, the teams I work with often start by enumerating the work within the original issue. If you need to, you can use a custom field to add a special place for this information, or you can use plugins that add functionality like checklists to Jira issues.

Sometimes, the original issue is decomposed into two separate bodies of work. In that case, a new issue would be logged and linked to the original. Other times, the work is more tightly coupled but can be divided among multiple people. In those cases, subtasks may be more useful. If the work is likely going to be done by one person, it can just be listed out in the original issue itself.

---

In the end, it's about striking a balance. Having more issues or sub-tasks may increase visibility, but it also takes a little more time to enter the issues and make sure the information in each one is correct. It's a balancing act depending on who is doing the work and what the unit of delivery is.

Answer 3

Either they're small enough that it's quicker to just get them done rather than creating a Jira task

Reasons you may want to track such a small task include:

• Tracking it would help the team to coordinate and synchronise
• Tracking it helps you to gather statistics on this type of task, which might then allow you to adapt your process (for example by automating a recurring manual task)

This doesn't mean you have to track it, just that if there is sufficient value it may be worth tracking it.

or the task is part of the planning process

Scrum anticipates the team spending up to 10% of their time on preparing for future work. A small task that is part of the planning process fits in this 10% and so is already accounted for in the Scrum approach.

There seems little point in tracking such a task unless you plan to do some kind of analysis on your planning process.

Answer 4

I've done several small projects over the years for Apple, and so I can attest that they have (or, had ...) posters on the walls which said: "Put it on the RADAR!"

("RADAR" being the internal management system which they use for almost everything.)

"No matter how you do it, and no matter how small the matter may 'seem' to be," stick a push-pin through [the poor insect ...] and stick it on the board!" Don't allow the existence of it, nor the possible significance of it, to escape official notice. (Even if you never bother to "assign hours" to it.) The most important thing for posterity is to document that it existed.

Sure, it's fine to initially use "a set of bullet points, even one tagged (say...) 'FYI' that you keep adding to." If anyone at some future date needs to rearrange things, "so be it." For right-now: "put it on the RADAR!"