Small development team with big amount of tasks for different projects - how to?

Question

We are small team of 4 developers who manage 2 large websites + 4-5 small websites + we have a channel for customizations / development service (one time service).

With all websites on support we work by hourly rates. With customizations (we moved them into separate project) we make estimations and sell them by fixed price.

We have different tasks from small (like moving a button, changing color) to large (2-8 days' length, like developing a new extension with some complex logic).

On support we have very different loads from time to time. Some days we have only a few tasks, other days they can add 1-2 big tasks and 20-50 small and mid-size tasks as well.

Currently we create such task types:

1. Fast Task - very small tasks can be done without confirming from client, like <= 1-2h
2. Task - usual task > 1-2h
3. Bug - We know how to represent it at least. Sometimes we know how to fix, but sometimes we can't estimate it (need to research, research taking for example 2h and after that 5min to fix it)
4. Problem - something we even can't reproduce or we don't know how to deal with. Can't be estimated and planned.
5. Epic - used to decompose big tasks if possible. Sometimes used just to group a lot of tasks by one responsible manager from client side, adding new tasks related to one big story. As an example, UI/UX improvements with AB testing for a long time.

We make estimation on all tasks where possible.

Also we always have some tasks that can't be closed for a long time even if they are completed from our side. Client developers have no time / didn't finish code on their side (CRM, prepared products etc.) - we need to wait on such tasks for a long time and all those tasks are open in the list to not forget about them; they can be in status "Customer Testing" for example, but still in the list.

At this moment we have about 200 opened tickets/issues.

Very often, the client is asking for something ASAP and most likely they would ask this at the same time as another client or ask for a for few tasks at the same time :)

Clients sometimes ask us when some future task would be finished.

Which software can we use to deal with this and how do we need configure it for the best way to handle all of this?

I mean, how we can plan and get real deadlines in such chaos?

Also need to say - currently we use JIRA and I tried to create short sprints like 1 week, put there work for 1 week and in that case I can plan for example for 2-3 weeks ahead. But this doesn't work for the following reasons:

1. Sometimes our estimation is very different from reality - we are working on this + we plan a sprint for just 4 days (1 day is for such mistakes and bugfixing)/
2. Some tasks are finished on our side, but not tested or not prepared by the client and by the end of the sprint we need to move this task to the next sprint over and over again.
3. JIRA allows to plan a sprint only by Original Estimate, but such tasks as in point 1 already are almost done but not closed. If we close them and later in 3 weeks when the customer would test it we will create another tasks - then the total time by task would be separated and we can't see how long it took. If we close the task - it is not merged yet to master - we can lose it at all and need to waste time to find the task and branch for it (we use branch names by task)
4. Some tasks can't even be estimated as I wrote before
5. What if a task is already on production, but after 1-2 weeks we found a bug in it? Reopen would have Original Estimate, Subtasks can't be included to sprint.

I thought about EasyRedmine with their resource planning, but not sure if this can help to handle all of this.

So please, any ideas or links where to find how I can manage all of this and how to make this processes better? We are ready to change the whole process if needed.

Answer 1

Scrum as a process is a good way of delivering a project which will take several sprints to deliver. It is also very fashionable. However it is not such a good process for delivering bugfixes and small change requests with near-zero lead times. Using a Kanban board on JIRA would be the ideal solution, as Daniel mentions above.

Sometimes our estimation is very different from reality - we are working on this + we plan a sprint for just 4 days (1 day is for such mistakes and bugfixing)/

Without the structure of a Sprint, over-running an estimate won't have the same administrative consequences.

Some tasks are finished on our side, but not tested or not prepared by the client and by the end of the sprint we need to move this task to the next sprint over and over again.

More Sprint admin that you don't need to do with Kanban.

JIRA allows to plan a sprint only by Original Estimate, but such tasks as in point 1 already are almost done but not closed. If we close them and later in 3 weeks when the customer would test it we will create another tasks - then the total time by task would be separated and we can't see how long it took. If we close the task - it is not merged yet to master - we can lose it at all and need to waste time to find the task and branch for it (we use branch names by task)

Again, on the Kanban board there is no need to artificially close a task. Leave it open until it is truly done, and log the time spent on it in one ticket. Bugfixes as a result of testing should be included in the lifecycle of the original ticket. Further change requests should be separate tickets.

Some tasks can't even be estimated as I wrote before

Doesn't matter on the Kanban board.

What if a task is already on production, but after 1-2 weeks we found a bug in it? Reopen would have Original Estimate, Subtasks can't be included to sprint.

Bugs identified in "done" tickets should be set up as new tickets. If this is happening often, you should take a look at the robustness of your testing processes. In general I avoid using sub-tasks in JIRA because of the limitations. Nothing to stop you from linking the new bug ticket to the original feature ticket to maintain traceability of the work you are doing.

A couple of further points from me:

1. You mention in your comments to Daniel that Kanban does not allow you to track "how far through" a task the developers are. You can't reliably measure how far through a task somebody is - no task will be completed in exactly the estimated time. Tracking how much time is notionally "left" on a task will not make a difference to the developer's ability to deliver it. Communication is the key.

2. WIP limits are optional. Just because you are within a WIP limit doesn't mean you are not in trouble. Did I mention that communication is the key?

3. The numbers you mention sound like you have too much work. Look to address this, either by increasing your developer resource of decreasing the expectations of your clients. A software/process change will not double your capacity overnight.

4. Who prioritises your work? You don't mention whether this is happening or not. Prioritisation is more efficient than picking up work based on how long ago it was requested.

Answer 2

I'm not sure that a software option will solve your problem.

I would definitely look at Kanban as a way to improve the flow of work through your teams. You can leverage it alongside Scrum or on its own if you want. It's important to use all of the practices of Kanban, not just the board. Make sure you are limiting work in progress, measuring flow, and making small incremental improvements. This is what will really help you improve your ability to handle all that work.

Also, be careful of overburden on the team. Many teams who are overwhelmed are actually working slower because of it. Henrik Kneiberg explains the problem well in this video:

https://www.youtube.com/watch?v=CostXs2p6r0

Again, this is where those strict WIP limits come in.

As for software, JIRA's Kanban boards work fine, but if it's just a few of you, sticky notes and a whiteboard do the job really well too.

For setting expectations on features, Kanban mostly uses average lead and cycle tie to calculate this. For larger projects you can also use burnup charts, but that can be difficult with a lot of competing priorities.