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.

  • 1
    Hi Kudja, welcome to PMSE! As your scenario stands, there are multiple questions being addressed, such as 1) how to manage bugfixing and planned dev 2) how to define priorities across different clients 3) how to deal with activities that are on the backlog but have external dependencies (amongst others). Although all questions are very valid, they may be either already answered on specific, separated questions and they´re making your own question too broad. Could you please break it down into different questions (after searching for possible similar ones)? – Tiago Cardoso Sep 23 '17 at 18:58
  • The Scrum Guide – Alan Larimer Oct 3 '17 at 17:36
up vote 2 down vote accepted

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.

  • Thank you for detailed answer. Will try to use Kanban again. Prioritisation coming from client, but we have 6 clients so sometimes they ask ASAP alltogether. After I combine there priorities together and getting my between them. – Kudja Sep 21 '17 at 22:05
  • I don't telling that I need exact time for start and deliver, but we need to answer somehow when we can deliver some task, it's very important and problem is I can't see in such amount of tasks when we can deliver something, only nearest planned work. Sometimes we have exact due dates from client - what we need to do with them? Add them higher priority? Sometimes I also have another problem - developer has 20 tasks on it, part of them in status Customer Testing + 10 of them small, in that point I don't see that I need to assign new tasks for that developer. – Kudja Sep 21 '17 at 22:16
  • So still I don't undertsand how you can manage all of this without some knowladge about how much work (in human hours) you currently have. – Kudja Sep 21 '17 at 22:17
  • I also thought about separating tasks into different boards by some property, like estimated hours <= 2 and > 2, but not sure this would work. All this making me thinking that I need one more junior or mid-developer who can manage that bugs + teach on them, and in that case probably I can separate boards ))) – Kudja Sep 21 '17 at 22:21
  • Re:Prioritisation - you can't treat each client equally. Tasks with real due dates (and not deadlines the clients are making up to get you to do stuff sooner) should be prioritised. – Baracus Sep 21 '17 at 22:44

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.

  • Thx Daniel. We have kanban board for all projects, and we have no problem with limitations. Actually we working on tasks from start to end, so we not putting tasks on some In Progress columns for a long and we have no such problem. We deliver a lot of code, but still this not getting answer on how to say when we can deliver some future. So I can't see here how much hours developer needs to finish his current urgent tasks and to plan and put inside some new urgent task or say customer that he needs to wait till some date. – Kudja Sep 21 '17 at 18:53
  • Even more - Kanban not allows to see how loaded each developer, it showing only count of tasks, not real estimates in hours + it has very long list of tasks in it in such case – Kudja Sep 21 '17 at 18:55

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.