I am trying to figure out how project management can help my team complete tasks faster, and I started to motivate one of our Junior developers to start using Jira recently. But he quickly loses track and stops updating the issue status, because he has to learn too many new things.

** Updated example **

  1. Bob decides to read about topic X to complete a task.
  2. He updates the card with estimated time (study + task completion), say two hours.
  3. He found that the solution has got some security vulnerabilities, so to mitigate risk he decides to read the security guide which will take him 24 more hours.

While the task is only worth 15 minutes for an experienced developer.

The main question is to forecast the estimated time.

How do experienced teams measure task progress when developers have to learn many new things during the development cycle?

  • As a non-novice developer, I still spend a lot of my time researching and learning. I feel this is often expected and integrated into my work as a necessary means to an end. What (if anything) distinguishes the learning progression of novice developers from those with experience? Commented Aug 11, 2020 at 0:38
  • You asked what distinguishes the learning progression of experienced developers? I think it is transfer of learning. e.g. if you know one language well you just need an extensive overview of another similar language to get started. Commented Aug 11, 2020 at 17:39
  • Distinguishes it from what? I don't understand what you mean. Commented Aug 11, 2020 at 17:41
  • But at workplace you have to create a balance in your learning and completing the tasks at hand. If the new dev go too deep in learning and ignore the tasks at hand altogether, how do we measure the progress of task. Commented Aug 11, 2020 at 17:46
  • Maybe the issue is not that the person needs to learn so many new things, but that they are bad are being self-directed. Commented Aug 11, 2020 at 17:47

7 Answers 7


Your problem is you've got too much granularity. Do you really need to know that this specific task will take this specific developer this specific number of minutes?

My question is... why?

Many modern Teams, aware of the inherent difficulties and inaccuracies of estimation, take up a less granular approach in order to make that inaccuracy (reality) more obvious.

Instead of estimating individual amounts of time for individual... individuals, consider estimating using relative effort - Story Points.

That way, it doesn't matter if the task takes Bob 24 hours but Alice 15 minutes. It's still a 1-point task. A 3-point task would take (roughly) 3 days for Bob and 45 minutes for Alice.

When planning, use the estimation for the whole team. The team of Alice, Bob, and Charlie complete 30 story points per month. For planning purposes, it's irrelevant how much of that is done by each person. You just need to know that next month, roughly another 30 story points will be completed.

  • Thanks for the detailed answer. I updated the question to make it more clear, especially the text in bold. Commented Aug 10, 2020 at 14:47
  • 1
    @RameshPareek Done.
    – Sarov
    Commented Aug 10, 2020 at 15:05
  • 3
    The funny part of this is that in practice, the sooner you let go of trying to provide accurate estimates of how much time things are going to take, the sooner you are able to provide fairly accurate estimates of how much time things are going to take...when you work with story points you'll quickly be able to figure out the team's velocity to a reasonable degree of accuracy
    – Cronax
    Commented Aug 11, 2020 at 10:44
  • 3
    @Sarov Let me give you an example: In a team with four developers. In a iteration the team achieves 112 points: DevA 8 points, DevB 8 points, DevC 32 points, DevD 64 points. The average per developer is 28 points per iteration. If 2 devs go on vacation the velocity should be 28*2=56? Depending on the devs who go on vacation, the velocity could be in reality 32+64=96 or 8+8=16. That's a lot of difference from average 56. That would be the velocity not taking the specific devs on consideration (I understand you said: it does not matter how many points each one does individualy, Bob or Alice) Commented Aug 11, 2020 at 15:34
  • 2
    In general people going on vacation will change the velocity based not only experience but also type of task, changes in team dynamics with people gone, and a hundred other things. The best way to deal with it is to make a best effort guess and realize that it could be wrong.
    – Erik
    Commented Aug 12, 2020 at 14:42

Trying to figure how project management can help my team complete tasks faster

Project management, and tools like JIRA, are (in the context of software development) ways of making your project move faster, and more reliably, by eliminating waste and sharing relevant knowledge. They also can be of assistance when estimating the time a certain part of the project will take to complete, but your mileage will vary, a lot.

And I'm afraid they are not going to help you with your main question:

How do experienced teams measure task progress when developers have to learn many new things during the development cycle?

This is just a special case of the more general question: How do we estimate the time a task will take when we don't even know how we are going to implement said task?

This question lies at the core of project management in software and while we know the answer, a lot of developers, especially those that are heavily invested in one methodology or the other (like Scrum, RUP, what have you) will either have a hard time admitting this, or take it for granted and so expect people to see everything they say on the subject in this context:

We don't.

People have been looking for a reliable method to estimate software projects since the dawn of time (1970-01-01) and what we actually have learned, but what a lot of proponents of PM tools or methodologies would rather not mention, is:

There is no such method.

Or, like Fred Brooks stated years ago There Is No Silver Bullet. Both this book, and his other classic The Mythical Man Month should be required reading for anyone who dares to venture in the field of software project management. The fact that these books are from 1986 and 1975 respectively and are still relevant today tells you that they contain very fundamental truths about software development. I will try to summarize the main problem as best as I can:

  • It makes no sense to re-invent the wheel, so if there is an existing solution for you problem, you implement that and you don't create your own.
  • If, and only if, there is no proper existing solution do you write your own code. This means you in fact are inventing the wheel so to speak.
  • There is no method to predict when an invention will occur to someone.

So what you are looking at with tools like JIRA or methodologies like Scrum are ways to mitigate this fundamental problem, not solutions to it.

This means that they focus on the things you can know (things that are not part of the fundamental problem to be solved, of which there are a lot, like writing documentation, framework boiler plate, interface etc etc) and on sharing knowledge so that you at least use all the knowledge available within the team. And for the things you can't know, they usually have some rough estimation method like "compare this task with another task that feels about the same in size". I've put emphasis on feels to underscore how fundamentally flawed and unreliable such a method must necessarily be.

To further explain the point, please take a look at these stats.

Among other things, it is mentioned (celebrated even) that only 70 percent of projects are delivered on time, and there is an average 27% cost overrun. (And please note the paragraph about "black swan events", they are very relevant to this story). No construction company would survive if this was their average, yet to us in software it is normal. How could this be in a field that has been attracting the best and the brightest for decades now, unless there is something very fundamental preventing us from doing better?

That's not to say you shouldn't use these tools and methodologies, you definitely should, but you should be careful not to expect results that are, as far as we know, impossible.

  • This is an excellent answer! Although I seem to have seen many construction projects with far worse overruns... So I am not sure how bad those stats really are ;-) Commented Aug 12, 2020 at 14:34
  • @user2705196 Those cost overruns are usually for the client, not the construction company :) Though the same may be said about software shops that service the public sector, the whole song and dance around tenders is remarkably similar, at least where I live. But I used to be a "calculator" (don't know the proper English translation) for a construction company and we used to on average be within 10% of the eventual real cost to the company. I switched to software engineering 15 years ago and never saw those percentages again, I hope my answer reflects what I learned about why that is.
    – Douwe
    Commented Aug 14, 2020 at 12:17

You are saying and asking a few things in your question, so I'll take them one by one.

How do experienced teams measure task progress when developers have to learn many new things during the development cycle?

The same way you measure any other task progress: from start to finish. Does it really matter that a developer used their knowledge to directly solve the task, or that they needed to learn some stuff before, to find out how to solve the task? You had a task in "to do", now it's "done", you now know how much it took. Progress is measured just like with other tasks: you work some time on the task and estimate how much more you think you have left. Since you have people that need to learn stuff, that estimate will most likely come out wrong, but that's what it is, there is no magic formula to get out of the situation.

If you are worried on the progress on the actual task and want to separate that from learning, then split the task in two: the actual task, and an "analysis" task and track progress on both. You basically give time to the new developers to learn what they need and track their time on the analysis task, and once they are confident they know what needs to be done and how, they start work on the real task.

But he quickly loses track and stops updating issue status because he has to learn too many new things.

There are two things here: the learning part, and not updating the issue. These two things are unrelated. If you work or you learn, that's consumed time that you need to be communicating to everyone else by updating the status. Updating the status is a matter of discipline. Communicate to the developers the importance of communicating statuses on their work.

While the task is only worth 15 minutes for an experienced developer.

Maybe that is so. But if a new inexperience developer works on it, then that estimate is completely useless. Have the experienced developer do the task if the new developer takes too much time to learn. If that's not possible, or you want the new developer to do it, then accept that it will take longer. As an aside, estimating in 15 min increments is a serious red flag most of the times, especially when considering different skilled people to work on a task. That's why Agile team prefer to estimate in Story Points and not in time. Maybe that will work for you, maybe not, but be aware that an estimation is just that, an estimation. Story Points are a better concept to express this than using hours.

The main question is to forecast the estimated time.

My question to you is "Who does the forecast?". If the experienced developer forecasts the task and the new developer works on it, the forecast is meaningless because it will take more time (with the learning time included). If the new developer forecasts the task and the experienced developer works on it, the forecast is meaningless again because it will less time now (no learning time necessary). And if the developer who does the forecast also works on the task, you also have no guarantee because a forecast is also an estimate and can be wrong.

  • Thanks for the effort put in. There should be something in JIRA that can keep track of learning progress of developers as majority of developers spend so much time learning and exploring new things when confronted with some tricky situations during work. Or may be a separate EPIC should be created for each learning task and stories for sub topics they study. Atleast to make sure they are learning and not playing StarWars. :) Commented Aug 10, 2020 at 19:03
  • 6
    @RameshPareek why? What's the point of all these measurements? If you want to keep track of who's watching StarWars - JIRA is the worst place of all. There needs to be a senior developer who oversees those newcomers and he'll see if someone's slow, fast or just lazy. Commented Aug 10, 2020 at 20:34
  • 4
    @RameshPareek: Jira doesn't magically know how to keep track of thinks. People need to put in the information. If a developer puts in 24 hours spent on a task, JIRA can't tell you that 4 of those hours were used playing StarWars. You either trust your people to do their jobs to the best of their abilities, or you are forced to police them or micromanage them, which are completely different problems (and worse problems) than that of tracking progress on tasks.
    – Bogdan
    Commented Aug 11, 2020 at 8:41

Estimates are Estimates

The purpose of estimating tasks, or stories, is to get an approximate mapping between "time spent" and "work done", which of course is mostly about answering the question "Will this piece of work get done by this deadline?"

However, it's really important to remember that estimates - whether they're done in actual time increments, or in story points, or in T-shirt sizes, or whatever - are estimates of the complexity of the task based on the knowledge of the people doing the estimation, at the time they produce the estimates. An experienced developer may look at a task and already have all the knowledge he needs to estimate it accurately, while a junior developer will potentially need to factor in a larger analysis - and, as you've noted, they may discover things during that analysis that affects their understanding of the task in a way that changes their estimate.

This is a good thing. It represents learning, and a growing knowledge within the team. It means that the next time the task comes up, the junior developer is better equipped to handle it, and will estimate it more accurately.

Ultimately, you want the estimates to stabilise as the team gains experience, so that while an individual task may not always live up to its estimate the work as a whole progresses at about the predicted pace, i.e. the team achieves a stable velocity.

Estimates can be revised

This should go without saying, but if information comes in that changes the understanding of a task then you shouldn't sweep it under the rug. Does the quick-and-simple solution introduce security risks? Then the team should be reviewing those risks and determine their impact on the scope of the task. It could mean breaking the task up to better reflect its new-found complexity, or it could mean de-prioritising the work until the security implications are better understood, or it could mean raising the priority and/or profile of the work to ensure that the security risks are appropriately treated and mitigated rather than left to fester (and if your team has a charter, or a similar agreement, you may want to include something in it about the relative priority of work - e.g. focus on delivering a stable, secure product over adding new features).

Agile Work is Team Effort

It is very easy to fall into the trap of thinking that since the senior developer can do everything faster, that they should be given all the critical work. This can be good for getting things done in the short term, but it is bad for the team in the long run.

Part of estimating the effort of a development team should include estimating the development of the team's skills to make them better able to handle work in the future, even in the face of uncertainty. This means incorporating time for training and learning - either as explicit tasks that form part of completing the work, or by reducing the team's anticipated velocity to account for the short-term efficiency loss. But it also means considering ways of better leveraging the team dynamics to make this happen faster.

Pair Programming (or just "pairing") is a practice where two developers are assigned to the same task to work on simultaneously. There are a lot of different arrangements, but one common one is to pair experienced and junior developers together and have them take turns writing code while the other watches and either learns or provides feedback. In your example, this means that the 15-minutes-for-the-expert-but-24-hours-for-the-newbie task will probably take some amount of time in between the two estimates, but it results in the junior developer having the knowledge that would have otherwise taken them days to acquire.

Communication is a Core Agile Practice

Possibly the most important point that seems to be missing from your example is the communication that happens in the team. There's a task on the backlog, and your junior developer is giving it a 2-hour estimate (that they later revise upwards) while your senior developer is giving a 15-minute estimate. This should absolutely be something that comes up in your stand-up, and is an opportunity for the senior developer to help the junior developer to study up on the system and for them to both gain an understanding of the other's perspective.

It could also be the case that the junior developer learns something that the senior developer - or the rest of the team - doesn't know, which is an opportunity for them to share this info with the team to lift everyone's abilities.

It's important, though, that the team has the right environment to enable this. Openness and Courage are two of the driving principles in Scrum, but they apply to any Agile team (or any good team, really). Your junior developer should feel empowered to come to stand-up and say "I'm working on task X, I've read up on it and I'm concerned about the security implications. I think it's going to take me another day to feel confident with dealing with them.".


The less you know about how to complete a task, the more difficult-to-impossible it becomes to come up with even a remotely credible estimate for it. If the junior developer has no real idea what's required yet, any estimate you get is going to be worthless. There's no process that can fix that.

But it may be worthwhile to take a step back and distinguish between a few types of learning:

  • Learning required to complete a particular task. Many tasks require some degree of learning. You want to, say, create a button with rounded corners, so you look up how to do that, either for the first time or because nobody can memorize every API. That kind of learning can be built into a task's estimate, because you already have a decent idea what you'll need to learn to accomplish the task. Of course, once you dig into it, you might find that buttons with rounded corners are actually surprisingly complicated, at which point you can revise your estimate upward, but this is the common sort of research-as-you-go that every developer does all the time.
  • Learning required to even estimate a task. Your boss tells you to add a feature to identify whether a photo contains a bird. At this point, you don't have enough information to provide a useful estimate. You'd need to research what's possible in terms of image recognition, come up with questions to narrow down the requirements, and propose possible options once you know what exists and how well they meet the requirements. You might prototype something to help figure out whether an existing open source package or commercially available solution can help or what kinds of training data you'd need to collect to train an image classification model. That all is one or more tasks themselves, which can be estimated (e.g. "I'll spend two days researching and then come back discuss possible options"). There is no sense in even starting to estimate the time for the entire big project until this research is complete—you don't remotely know yet whether it requires hours or a team of experienced researchers working for years.
  • Learning background knowledge in general. Any project will have some baseline level of knowledge required to be useful. This includes general knowledge about the languages and frameworks being used, including those needed to write tests. Reading the security guide is an important example. It might be knowledge about the industry and problem space. Or maybe some learning about the development methodologies and tools in use. I'd include setting up a development environment in this category as well. It could include anything from reading documentation to completing tutorials to taking courses. This kind of learning is separate from a particular task. There's no point in estimating any of it because it's not a task, but it needs to be factored into the onboarding process as someone starts on the project.

But to back up even further, you've framed the problem as one of estimation, but the core issue sounds like it's really about onboarding and mentoring a new inexperienced team member. It sounds like you're worried that this new developer may "go too deep in learning and ignore the tasks at hand altogether." That's only possible if you expect them to go off and learn everything on their own. Instead, has someone been assigned to help mentor this person and facilitate their learning?

Worrying about the estimates and productivity of someone who hasn't "read the security guide" sounds fairly pointless. If they lack the background knowledge to meet your security standards, the best-case scenario is that they're unproductive, and the worst-case is they introduce a major security vulnerability not otherwise caught by your development process and cause extreme negative productivity.

Beyond that, it sounds like this learning is being done solo, which may be inefficient and is leading you to worry the balance of learning and productivity may be off. If a task truly will take an experienced developer 15 minutes and the inexperienced developer 26+ working hours, it likely makes more sense to pair them together and turn completing the task into a learning experience. And during that process, knowledge gaps may emerge that point to the need for more learning—"oh, looks like you don't know what a SQL injection vulnerability is. Why don't you go learn about that and how to prevent them with FRAMEWORK before you pick up another task?"


Allow the junior developer to charge his time to a "training" task when he feels he is learning and not actually working on the fix.

What would your senior staff charge their time to when attending a management meeting?


Measuring task progress when new team members need to spend time learning can be challenging in project management. Ovel.sh is a great tool that helps track and manage task progress. It allows team members to log estimated times for both learning and completing tasks and record detailed progress in their daily journals. With daily check-ins and work hour logging, team leaders can better understand each member's progress and learning needs, leading to more accurate time forecasts and adjustments.

New contributor
Jagger is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

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.