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?


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: and updated #3


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.


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.


We’ve recently experimented with a bunch of solutions. Also because we noticed we weren’t able to react quick enough to any ad-hoc customer issues or small tasks anymore as our features were taking up all our team’s resources.

At first, we decided to free up one team (1 dev, 1 designer) for 2 weeks in each cycle. Assuming that they would be able to pick up “anything that comes up or are small random tasks” and spend the rest of their cycle time on an actual planned Small Bet.

However, we also noticed that it was very hard to find the balance. The team that was assigned to these “ad hoc” things ended up doing “ad hoc” the full cycle.

That’s why our new approach is to just take that fact as a given, and always have one team (1 dev, 1 designer) on what we now call “First Responder and Housekeeping”. The people in that team are allocated to that for the full cycle, and they have two main responsibilities:

  1. Picking up any ad-hoc issues with our application or giving some customers some extra help getting stuff done on our platform. This is what we call being the First Responders, eg Bugs + Customer Success
  2. Have a list on our Products team Basecamp which is called “Housekeeping” where this team picks items from when they are not working on some First Responder issue.

Our other two product teams can then fully dedicate the cycle on planned Bets (big and small) whereas this Housekeeping team can focus on everything ad-hoc.


I’ve been thinking about a similar approach. Keen to hear how this works out for you :slight_smile:

1 Like