How to deal with very small projects/tasks?

1

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?

4 Likes
2

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

4 Likes
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.

3 Likes
4

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
5

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.

8 Likes
6

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

1 Like
7

I love this and I am interested in hearing a little more about the First Responder/Housekeeping team’s process.

  • Are they personally prioritizing the ad-hoc work, or does that generally get done for them?
  • Do they do anything special to prevent from stepping on the batch project teams’ work?
  • You mention “bugs + customer success” – does this team mainly work with a customer support team, or are they actually interacting with customers?

This seems like it could work really well for our team.

8

Hi Matt,

Thanks for the feedback and interest! I’ll try to explain a bit better based on your questions:

Prioritization is a mix of a few things. As “external” input, we have things coming in over the cycle that our Customer (facing) team vets and gives an initial priority. If anything important pops up there, then the Housekeeping team is asked to take a look on short term or if a quick discussion if it can be moved to later.

Then, we usually have a list of “ongoing concerns” in our “Bugs & Support” Basecamp project. Things that are not critical priorities, but popped up in more than one occasion on the past. The Housekeeping team uses this list to “cherry pick” from, without too much guidance up front. Everyone in our team is smart enough to distinguish between important and less important issues from the past.

Third, the Product team comes together in each Break Week between our cycles. In the days before each Break Week kick-off, everyone can put items on an “Inbox” list that is parsed at the beginning of the Break Week. This list is usually a bit longer than we can achieve in a single Break Week, so any remaining items are also good input for the Housekeeping team as soon as the cycle starts.

There’s currently no policy or rule in place that prevents them from stepping into a Cycle project or the other way around: when a cycle team touches on something that’s being worked on in Housekeeping. Apart from the communication we have in our generic Product team and in our Break Week coördination it comes down to good communication and keeping an eye out. We also have a cycle kickoff post every cycle, so the Housekeeping team is fully aware what areas of our product are being worked on in regular cycle project. Since the nature of Housekeeping tasks are pretty “ad hoc” and random, it’s usually not the case that it touches on anything that a Cycle team is already working on.

Indeed, the Housekeeping team works very closely with the Customer team. Sometimes getting “inward” feedback/topics. Sometimes “outward”, as in: “Hey, we’re doing this migration that impacts the customer. Customer team, can you help us communicate outward?”. In most cases the Customer team handles the communication and follow-ups, also to verify if they understand what the hell the Product team wants to achieve. But this is not a strict rule to follow. We don’t have a rule to have “gatekeepers” in place. If it makes sense for someone from the Product team to arrange or announce something to a customer directly, that’s all good. Sometimes even better!

I hope the above gave some answers to your questions!

The gist of having a dedicated Housekeeping team around is that when everyone is focused on “bigger” Cycle features, you forget or keep postponing the small things. And those are sometimes as important as bigger feature releases in the eye of the beholder (the customers). And the Housekeeping team serves as “The Shit Umbrella” for any (tech) issues coming up that our customers or Customer team can use support in.

6 Likes
9

Dude - so helpful. Thanks a ton for the explanation and detail. If I could send you a beer, I would :beers:

1 Like