As a Scrum Master / Agile Coach, what is the correct approach for dealing with Engineers in a team who take longer than the rest of the team to complete their tasks.

Since we are using Kanban we aim for between 5 and 7 days average cycle time i.e. when they pick up a ticket to when they push it to done it should be between 5 and 7 working days.

Thus far I have simply made this information available to them with dashboards.


4 Answers 4


Firstly, look at whether you can split your stories any more.

Secondly, why aren't the engineers on your team cooperating. The way your describing your system sounds like a you've set a minimum work in progress limit of one story per developer. Of course your cycle time is high (cycle time = wip / throughput after all). Instead cooperate on things to reduce work in progress.

I can tell you suspect that some of your engineers are better than others. I think the thing I've already suggested, encouraging cooperation on tasks, will go some way towards bringing the skills of the weaker engineers up. There are a lot of other people management factors however. I won't list all of them, but do people get the tools they need, the training they want, slack time to improve their skills, time to go to conferences etc etc? Are you involving your best developers as key decision makers in the hiring process? People have written books about this sort of thing, so I'll stop there.

  • Thank you for your response. They aren't measured individually no, we have the same average cycle time goal of 5-7 days. I think you are right they need to cooperate more and work together. Will see if anyone else has a response.
    – TheLearner
    Commented Apr 3, 2017 at 13:01
  • Upvoted. @TheLearner: This answer does the job. Commented Apr 3, 2017 at 15:14
  • 2
    @TheLearner: Splitting the story is very important. I've done it two ways - 1. allow anyone working on any story/task to split any story/task to subtasks. 2. have periodic meetings to discuss stories (if you were doing scrum instead of kanban this would be your sprint planning). In my old job we don't allow any story to exceed 2 days before being split. In my current job we don't allow any story to exceed 1 day. Now, after split, since everyone agrees that each story takes 1 day to finish or less you can spot bottlenecks within 24 hours rather than after 7 days
    – slebetman
    Commented Apr 3, 2017 at 16:08
  • 3
    @TheLearner: Also important is how to deal with bottlenecks. I personally never blame slowdown on individuals. Instead I assign more resource to the bottleneck - maybe they need someone else to help them, maybe they can't reproduce a problem if all else fail I personally go and pair with the person working on the bottleneck until we solve it together - that servers 2 purposes, first two heads are better than one and second this is the perfect time to mentor a junior employee
    – slebetman
    Commented Apr 3, 2017 at 16:11
  • Set the teams WIP to be one less than the number of people on the team. Commented Apr 8, 2017 at 15:22

First of all, faster isn't always better. One of the engineers I've worked with finished his stories extremely fast, way faster than the rest of the team. But he'd often use quick and dirty shortcuts, and the testers explicitly gave any user stories from this engineer extra attention. He produced different bugs than the rest of the engineers, more difficult to find, but often with a lot of impact.

If there's enough trust in the team, discuss the differences in speed with the whole team and ask them what factors they see that can explain the differences. Some possibilities include personal factors (motivation, drive, perfectionism), skills and knowledge, amount of distraction (soloists vs the people who are always helping others instead of doing their own tasks), or different views on quality/scope/definition of done.

Try to pair the faster engineers with the slower ones (and in general, encourage cooperation) -- both of them can learn from working together.


If you want to bring your cycle Time down, then it's time to apply The Theory of Constraints. Look for where the work is piling up, then work to remove the bottleneck.

Of course, the work has to be visible enough first. A simple todo-doing-done board isn't going to cut it. You need to model the actual workflow in order to spot the bottleneck. Backlog-Ready-In Progress-Review-QA-Ready to Deploy-Done is a likely workflow. If things are piling up in QA, have some devs help. If things need reviewed faster, figure out how to make that happen. Do deployments take hours? Automate them. Etc.

As mentioned by others, the other lever you have to pull is the WIP limit. Reduce your WIP limit and the avg. Cycle Time should fall.

Most importantly, the team must leave enough slack in the schedule so that they can improve. It doesn't help to identify a bottleneck if no one feels they have time to address it.


We had the same issues: the team I took over as Scrum Master was considered slow by the POs, other devs and so on.

When looking into it, these are the problems identified (and solutions we implemented):

  • Backlog items were not clear. A lot of time was spent investigated stories during sprint => we split stories into Spikes (research), Stories, Tasks/Sub-tasks, Bugs. Now you could see clearly how long the research took for a story and how long the actual coding. I also worked with the PO to do more research before putting stories in backlog.
  • Next problem was that the stories (after implementing previous item) were not split properly. We split a story to be as long as a sprint or shorter, if possible. I raised this issue with Mike Cohn at his recent User Stories training; his recommendation is to split stories as much as it makes sense for the devs, don't waste much time to split them in the smallest possible, but definitely shorter than a sprint.
  • Next we addressed the issue you mention - are some devs slower than others? Of course, but in our case it was not because the fast ones were among shortcuts, it's caused by seniority and knowledge of business & product. So we went for pair programming: a senior programmer pairs with a junior to distribute knowledge and learning.

The above worked very well. We increased our velocity with at least 30% in only 4 sprints. But I am aware that the increase might come from the fact that we didn't estimate stories properly to begin with so we continue working and monitoring.

TL;DR it all starts in planning, how you split and estimate stories. Start from there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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