In particular, there can sometimes be patterns of failure demand that go undetected if one never decides to track small tasks. If the tracking method can be light enough, it may help you uncover something you didn’t know you didn’t know.
Thanks for the comment. I could definitely see where that approach is useful for teams doing Kanban, because:
a) The number of items (of whatever size) is generally larger in a Kanban team than a Scrum team because Kanban is better suited to teams where scope and priority changes frequently (such as in a team that does production support only).
b) The items themselves are often created by someone other than the team, such as user submitting production support tickets. This reduces the time to track the items, which changes the equation about “time to track” should be less than “value of tracking”. I imagine this was the case in Joakim’s example, but he didn’t make that clear.
I think the approach could also be used for any team (Scrum, Kanban, or whatever) when there is a larger number of bugs(big or small) that need attention often.
On the other hand, for plain Jane Scrum teams that don’t do a lot of production support, I wouldn’t expect as many small tasks, and I would usually expect that the Scrum team is creating the tracked items (as opposed to users), so the “time to track” should be less than “value of tracking” equation is adjusted so that probably more teams won’t think it’s worth tracking.
When I think deeper about it, I find that many Scrum teams do this kind of “failure demand” analysis sort of by default, in the Daily Scrum when they talk about impediments and what they did yesterday, etc. I can’t tell you the number of time someone has reported “I got sidetracked on xyz” or “small task X took longer than I thought”. Once people hear that on a daily basis often, usually someone comes up with the idea to either do a root cause analysis or just attempt a fix altogether. So, one might say that the Daily Scrum encourages failure demand analysis by its very nature. Whether that’s as effective as tracking small tasks or not, hard to say.
I also just remembered an experience related to this. I was at a client and we received a couple of feature requests from the customer service department. Essentially, their “trouble ticket reporting” had indicated a large number of the same types of fairly small requests coming into their department(such as requests to change a password, for example). They did some root cause analysis and requested features that would allow the user to have these problems less often and/or could solve them themselves easier. Obviously, the CS organization operated much more like a Kanban team due to the nature of their work.
I have a team that current does about 60% production support of existing products but they are also the members that would be part of any project going on. While I can plan for a smaller amount of development during a sprint, should we plan the smaller production tasks like a new report or query that is new work but not a project?
If I understood your question correctly, I think are asking something like:
Your team does production support and “projects,” but they also do a third kind of work — new work that is not a project, but is related to production support somehow. I’ll call this “mixed work” for the purposes of our convo. Your question is, “Should we plan the mixed work” too?
Sure. Why not? I mean, planning ahead vs. planning “just in time” is something that you need to think about. For instance, if you were to “plan ahead”, how likely is it that this “plan ahead time” (which should be fairly short anyway) would end up as waste because the item got de-prioritized? If the likelihood of “planning waste” is high, then maybe wait until that likelihood goes down, or just before work begins on the item? There is actually a new line of thought in the Scrum Guide that allows teams to do more “just in time” planning for Product Backlog Items. The guide actually suggests that you could use time just after the Daily Scrum to do this.
Most of the teams I deal with are software development teams where the likelihood of the “planning waste” is low on a sprint horizon (usually 2 weeks), so I recommend that they plan items more upfront in Sprint Planning, because this usually allows them to work more efficiently inside the Sprint, and helps them track the remaining work in a sprint easier. Your team sounds different than these teams, so maybe a more “just in time” planning approach would work better for your team. You’ll have to ascertain that yourself.
I hope I’m not totally off-base as to your question. If I am, please let me know by giving some more context and I’ll try to give you “better honed” advice. Thanks again for the question.