How do companies measure task progress in project management tools (Jira) when fresher team members spent most of the time in learning?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.".

Answer 5

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?"

Answer 6

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?