Shape Up Forum

How to deal with very small projects/tasks?

As lots of others we are coming from the agile-world and currently have a backlog overflown with lots of projects of various sizes.
There are a lot of very small tasks, certainly smaller than the “small batch” project of two weeks, that might be worthwile doing. Examples could be

  • The current focus-order for a widget should be rearranged
  • Write to the log when the user closes the application

They sometimes describe very useful and wanted changes, but instead of an “appetite” of 2 weeks they would be more in the realm of 1-2 days. How would you deal with such tasks, when only two sizes for a project are available and both are fairly big?

3 Likes

I can think of several options:

  1. Use the Cool Down period
  2. Dedicate a ‘bug-smash’ cycle
  3. Dedicate someone to not be on a project team for a cycle and do these kind of maintenance tasks / issue handling. Change-up the ‘on-duty’ person on each cycle…

I believe all of these 3 options have been uttered somewhere (twitter or SvN). I’ll share the links if I can find them.


Edit: found the source for the holliday / bug-smash cycle: https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs and updated #3

5 Likes

I run into this all the time.

Receiving a list of 40 different tiny tickets that could be “just a quick fix” or cause much larger, cascading problems after implementation can be infuriating, especially if the majority of your focus is elsewhere.

I am not sure if there is a right solution, but after reading Shape Up I wonder if this ticket came up from a bug in the code, or a bug in our process.

Most of them for me are a bug in our process.

“I would have written to a log that the user closed the app if I understood why that was important the first time around”. Sometimes what is obvious to someone doing the design/shaping of the work isn’t obvious to the person implementing it. The edges are blurry until the person doing the implementation understands the job to be done.

I do my best to ask my client (or whoever is handing down the ticket) about 100 times “Why are we doing this? When has it been a problem last?” until my confidence and understanding of the work becomes clear enough that I feel comfortable doing implementation. Some clients find it refreshing, others annoying. When I get lazy, I pay the price when a million of these little tickets pour in.

Sometimes it is just a bug in the code. “I forgot to implement the focus-order correctly, probably should have been caught during testing, but I should fix that for accessibility issues” (or whatever).

These little things I do my best to prioritize these and batch them up (probably during the cool down period).

If it causes more problems to solve than it is worth, I may just leave it as a bug in the code. If it isn’t losing customer data, preventing people from accomplishing their job to be done, or making something completely inaccessible, it may just have to stay broken for a while until such a time comes to fix it properly.

Again, I am no expert, but I found that spending more time in the discovery/design side of things keeps the list of small tiny tickets more manageable, and provides plenty of time during your cycle to properly test things.

2 Likes

We have had some success baking this kind of work into our Small Batch team’s duties. Since most of that kind of work is engineering, our small batch engineers rotate on and off what we call “Bugster” duty every week or two over a 6 week cycle.

The Bugster triages tickets and knocks out small issues and priority bugs. We’ve found that a 1-2 week rotation is short enough to make it feel like a breather for the developer, but long enough to let them actually accomplish something meaningful.

As such, we try to assign 3 devs to our Small Batch team. This way the project work that team is tackling always has enough people to make reasonable progress.

3 Likes