Microtasking for Hyper Productivity and Happiness

What’s the biggest obstacle to making fast, enjoyable, and efficient progress on your project? How can you avoid losing your train of thought when interruptions pop up? How can your team deliver projects faster? The answer to all of these is Microtasking. Microtasking is a huge upgrade to any development process!

Microtasking - Hyper Charging Your Team's Productivity

What is Microtasking?

Microtasking is the process of breaking work items into very small tasks.

Microtasking is a way of a working that supercharges your entire creative process. It not only helps your individual creative process, but makes working as a team much more fluid, transparent, and effortless.

Microtasking is the opposite of the conventional large-story based workflow. It is one of the very best practical ways to arrive at a healthy high-flow software development process.

Conventional Work Flow

Most companies conventionally work on project by creating large user stories. These user stories are prioritized and eventually assigned to a team or a developer. Implementing user stories typically involves the assigned team or developer beginning work on the story, working on it for a few days or weeks, and then eventually checking in some source code with the completed feature.

This process is very common, but it suffers greatly from a number of pitfalls.

What are the big pitfalls?

Large user stories and work items that span multiple days are inherently symptoms of an unrefined and unevolved development process. Mature and high-performing teams do not use large user stories.

Key Benefits of Microtasking

1. Optimal Developer Flow State

A developer working on microtasks can disable all real-time communication tools, start working on a ticket, and finish the entire chunk of work within the Pomodoro window. Then, with the task fully complete, there is no cost of context-switching. You capture all of the incredible scientific benefits of being in a flow-state, especially greater happiness!

2. Effortless Team Parallelization

Building features as a team can be much faster with microtasking. There are countless times when a large story is taken by a developer, who goes off to work on the feature in a silo. You might ask how the feature is coming along 2 days later, and find out that the task was “much bigger than expected and touched so many parts of the system.” By using microtasking, there will be no large parts, by definition. This makes it easier for the team to swarm on the elements in the user story and tackle the different pieces of it.

3. Easier to Monitor

As a project manager, I want to have knowledge of how development is going for the critical features I am working to deliver. The more granular the detail on progress, the more easily I can adjust scope and resource allocation. Microtasks allow me to have up-to-date knowledge without needing to interrupt the team members for status updates.

4. Better Defined Tasks

Discovery is an often skipped part of the software development process. This inevitably leads to countless surprises during implementation. It’s very easy to create a very large User Story without really defining any of the details or acceptance criteria. However, with Microtasks, this is a virtual impossibility. You can’t create a ticket that will take less than 90 minutes of work unless you know the implementation elements.

How Big Should My Tasks Be?

A task should be small enough that it can be fully completed, from start to finish, in a single sitting.

On most projects, the recommended task size is 15-90 minutes.

For enterprise tasks, where there is the burden of cumbersome approval processes, it sometimes makes sense to size tasks ranging from 30-minutes to 3-hours.

No task should ever span more than one work day. This is the key thing to avoid! Cross-day tasks are incredibly risky to the project. They reduce joy, they decrease quality, and they increase project risk.


Q: My team works just fine with tasks spanning multiple days? Why do I need multitasking?

A: There are software teams that claim they work “fine” while releasing their software just once a year. Complacency and contentment with a glacial pace is the anti-thesis of a strong and mature software development process. If you want want a strong software devlopment process, throughput and lead time are your KPIs. Delivering real-world value to the customer rapidly is the way to know if your development process is healthy.

Q: What should I do if I start a microtask and then find that some other work is preventing me from completing it in the expected time?

A: Create a new microtask for the blocking work, and work on the blocking item(s) first. It’s always good to move a work item that can’t be yet completed back to the backlog. The faster you discover this, the lower the productivity cost.

Q: If I’m about to start working on a microtask at the end of the day, and I don’t expect to finish it before I leave for the day, what should I do?

A: Leave the task for tomorrow. Wrap up your day early, or work on some non-project work until the end of the day. You’ll be happier, more focused, and have better flow if you complete the microtask in one focused sitting.

Further Reading: