We are a facing an issue where some of our team members are not happy with the pre-planning/planning phase of our scrum sprints. Their concerns are, that during pre-planning developers do not have too much time to understand a task that have not investigated themselves, so making suggestions and point estimating is difficult.

So in fewer words, there is not enough time to understand a task and provide valuable feedback.

Their suggestions:

  • Reviewers should discuss tasks directly with the developer that performed the investigation and estimate the task, thus canceling pre-planning.
  • Present only complex/major tasks to the team during retro meeting for knowledge sharing (our work load has a lot of repetitive tasks so I can understand this one).

So, how should we tackle that?

  • 4
    "Reviewers should discuss tasks directly with the developer that performed the investigation" - who are "reviewers"? If you mean other developers, then that's basically what you do when estimating tasks. If you mean non-developers, then what if that developer isn't perfect and misjudged something? If they need to present their reasoning behind an estimate to other developers, and they say e.g. "I think it will take 3 weeks to finish this part", another developer might say "isn't that just changing 1 line of code" and that could lead to a much more accurate estimate or a better understanding.
    – NotThatGuy
    Commented Sep 29, 2021 at 19:02
  • 5
    Your vocabulary does not seem to match with Scrum. There is no "pre planning", nothing called "investigation" and the retro is certainly not to present tasks. Can you compare your working process to the Scrum guide and check whether you are actually doing Scrum?
    – nvoigt
    Commented Sep 30, 2021 at 6:14
  • Definitely need to understand what is meant by "reviewers" here.
    – Ian Kemp
    Commented Oct 1, 2021 at 8:47
  • @IanKemp we have default reviewers for merge requests, usually more senior members who have a better understanding and deeper knowledge of the product/system.
    – GeorgeKaf
    Commented Oct 1, 2021 at 11:16
  • 1
    I thought that's what you meant (i.e. reviewer = developer) but just wanted to make sure.
    – Ian Kemp
    Commented Oct 1, 2021 at 14:17

6 Answers 6


There is no planning or pre-planning phase in Scrum. I guess you are referring to Backlog Refinement and/or Sprint Planning (sprint planning is a relatively short time-boxed event and definitely not a phase). Backlog refinement and sprint planning are complementary activities when it comes to helping developers understand items on the backlog. Sprint planning meetings are focussed on the current sprint and time is usually limited so there may not be time fully to understand everything at that stage.

The idea of backlog refinement is that it's a background activity where the team takes time to refine the backlog, make estimates and understand things that will come up in future without the time pressure implicit in sprint planning. It can help to schedule some refinement meetings where team members have the opportunity to discuss things in advance so that sprint planning itself can be kept relatively short. If it happens that only one person is sure to work on a particular item then it may not be worth explaining it to others but usually teams aim to eliminate those key person dependencies by regular communication across the team. The team only needs enough information to be confident when a backlog item is ready to start and that it can be done in a particular sprint.

You mention retro meetings. Retrospectives are supposed to focus on how well the team is doing and where they can improve. I suggest you avoid using them for knowledge sharing.

  • Yes, you are correct, "phase" was not a good choice of a word. Usually our sprint planning takes around 1-2 hours. During that time we maybe have to point 10-15 or even more tasks.
    – GeorgeKaf
    Commented Sep 29, 2021 at 12:52
  • 4
    I think most pointing should be done during refinement meetings, not during Sprint Planning. By the time Sprint Planning happens, you should have tickets already to go, and it's just a matter of who works on what.
    – Xtros
    Commented Sep 29, 2021 at 22:17

Here's a more psychology-focused answer.

Agile decreases certainty to increase delivery speed of features. This trade-off means that you will never be 100% certain about what is required to develop a specific feature. (If you were 100% certain, it would be waterfall!) This necessarily means that estimates are less precise and more likely to be incorrect.

A developer who is used to waterfall and/or having their estimates used as hard deadlines, will feel intrinsically uncomfortable with such imprecise estimates because in their past experience, that leads to work not delivered on time, which directly translates into working overtime to get things done and/or unhappy managers. Even if that developer is now working in an agile manner, where they know that points are not equal to time, the bad experiences they've had in the past as a result of imprecise estimates are likely to translate into anxiety (often subconscious) around not estimating accurately.

Essentially then, the concern your developers are expressing around not having enough information to estimate accurately, could simply be them attempting to rationalise this anxiety that they may not even realise they have. As such, discussing this possibility with them could be a good way for them to potentially understand more about themselves, and lead them to be less anxious about estimation going forward.

Regarding not knowing enough about a task to estimate it accurately, this could indicate that said task is too complex and should be broken down further. But this could tie into trust; many developers are unwilling to estimate on something they themselves haven't investigated because they don't trust that the developer who did the investigation, did a good job of it. This is especially true if the investigating developer is more junior, or has a track record of not investigating thoroughly enough.

In the former case, the developers complaining about lack of knowledge should be expected to have more knowledge than the junior, and thus be able to assist the junior in estimating. Over time, as the junior gains more experience with the system and becomes less junior, their estimates will intrinsically improve. If they don't, the team needs to have a discussion with the junior to address this (escalating to management if the situation doesn't improve).

It becomes more complex when some developers don't trust another to investigate adequately. This almost always points to an issue with the developer in question; people don't build up reputations overnight. Again, this is a situation where the team as a whole needs to sit down and have a frank discussion about how this developer's lack of due diligence is affecting the team's performance and morale. This is unlikely to be an easy discussion to have, but sometimes the issue really is that the developer who is a problem doesn't know it, and merely being informed of it will prompt them to improve. If not, and/or if that developer is hostile to the notion, it is time to get management involved, and sometimes the simplest and easiest solution is simply to get rid of the bad apple because of the negative influence they're having on the team as a whole. Trust is so incredibly important in building a well-functioning dev team, and it's almost impossible to foster that trust when everybody knows there's a problem child they have to deal with.

Obviously, if a developer doesn't understand a particular task well enough, they're going to feel that there's little point in trying to estimate it. If there are many tasks where this is true, that developer is likely to feel they're not making a valuable contribution to the estimation session and/or that their time is being wasted. This can be particularly true of juniors, who know almost nothing about the system.

The thing is, it's simply not feasible to have everyone clued up on every part of the system, no matter what development methodology you use. Especially on larger systems and teams, different people are going to know more or less about different areas of that system - even the most senior developers will only know that certain sections of the system exist.

This by itself is not a problem, it's reality. What is a problem is when developers start being assigned, or choosing to work on, tasks that deal with working on parts of the system that are familiar to said developer. Then you start getting into a situation where knowledge is siloed, and that's a bad place to be.

This might not even be happening intentionally, because people naturally gravitate towards things that they know, and avoid unknowns. There are other factors that might cause developers to choose what they know: previously being in a stressful environment where output was valued over consistency (so getting work done fast was important, and you always work faster on something you know); or merely being one of those people who thinks that having more points completed in a sprint makes them a better developer than the rest of the team. (You should be wary of the latter kind; they often turn out to be poor team players.)

You need to be watchful to ensure that such silo-ing doesn't take place. If you do see it happening, all you can really is encourage the developers in question to work on other things, or to pair with their peers who may be less familiar with that part of the system. Trying to prevent it by manually assigning tasks to certain developers is unlikely to go down well, and is very un-agile, but may unfortunately be necessary in situations where the softer approach hasn't worked. Obviously though, avoid putting juniors on difficult system-critical work, and avoid putting seniors on basic stuff that is going to bore them to tears.

Ultimately, it feels like your team doesn't understand the democratic nature of agile. While it might appear more efficient to let people who know the work be the ones to estimate it, it prevents other members of the team - particularly the ones less familiar with that area of the system - from asking questions and gaining system knowledge from their peers. I've been in many planning sessions where a seemingly innocuous question from a very junior member has caused a big "oh c**p" moment amongst the most senior members, simply because the junior's lack of understanding highlighted something major that had been missed. Even better, because a junior often doesn't have the "indoctrination" into the way of thinking about the system that seniors have, they can often bring entirely fresh and valuable perspectives into how to tackle a section of that system that the team thinks they know.

Which dovetails nicely into the retrospective. A retro can and should share knowledge, but about the sprint, not the system under development. It's perfectly okay for a developer in retro to say "I discovered X about section Y of the system while working on the task, which made the estimate junk, but next time we'll all know so we can estimate correctly"; it's not okay for said developer to then follow on with a technical discussion of what they discovered. That sort of information should instead be conveyed by developer team meetings that exist especially for that purpose.

And perhaps that's what your team is missing. It's perfectly okay for the whole dev team to take an hour or two every sprint, sit down together, and simply discuss the system as they know it. Such a knowledge-sharing session is a valuable opportunity for juniors to learn so that they feel able to estimate more accurately, while also being a good way to prevent silo effects among seniors, and would likely solve the issue around uncertain estimates due to not enough knowledge. It doesn't have to happen every sprint, or involve all the developers; it can happen whenever someone has completed a big rework of an old subsystem, or added a new one, or upon a new team member joining. If the team really is agile, they decide as and when it's needed.

Developers generally have a very visceral (and understandable) reaction to the word "meeting", which is why I've been very careful to avoid it until now, but in a truly agile working environment (and I'd argue, any functional working environment) they should understand that knowledge-sharing is vital and part of their jobs, and a team meeting really can't be beat for accomplishing that. If they can get value out of it, that can also help to make them more motivated for the standard ceremony-type meetings like planning, estimation and retro.

  • I also believe that there is another reason behind this. It could be also that some developers feel they lose valuable time from their tasks and at the same time offer little to accurately pointing, because of maybe a combination long spring refinements and having to point a lot of complex tasks (that haven't been broken down or not investigated adequately).
    – GeorgeKaf
    Commented Oct 1, 2021 at 11:14
  • 1
    @GeorgeKaf Thanks for that - I've expanded on my answer to take those points into account.
    – Ian Kemp
    Commented Oct 1, 2021 at 15:00
  • Speaking as a sometimes-developer myself, my biggest source of hesitation is when I don't feel comfortable that I'm actually looking at everything I need to know – that all of the potential impacts to the thing that I'm supposed to be working on haven't been identified and therefore won't appear in my design and execution. Software, once written, is really a very fragile thing: if you have to go back and make major changes to it that you didn't anticipate/know before, quality degrades very quickly. "I might not need to act on it now, but I want to know about it now." Commented Oct 14, 2021 at 15:05

This means you are facing an issue in Backlog refinement. There is another thing that you can do - a spike. Depending on how critical it is, you may assign 1-2 days at max.

Honestly, the issue that you are facing seems more technical than related to planning. If I am not wrong then you would be delivering a potential shippable increment at the end of the Sprint?

So, think: where is the actual fault? A senior person in the Team? Not enough resources? Technical gap in what a product needs and the Team has to offer?

  • 1
    Welcome PMSE Jehan. Maybe "spike" was the term you were looking for?
    – nvogel
    Commented Sep 29, 2021 at 12:18
  • Thanks @nvogel perfect. That was the term :) It has been more than year I have lost touch with scrum :( Commented Sep 29, 2021 at 12:50

I agree with the earlier answers, but wanted to add a point from the Agile Manifesto that is also backed by research evidence: "The best architectures, requirements, and designs emerge from self-organizing teams." So the short answer to your question is, "Yes." As a coach, I suggest that your role is simply to help the team members negotiate a solution that everyone is comfortable with!

  • 3
    The answer to "how should we tackle that" is "yes"?
    – nick012000
    Commented Sep 29, 2021 at 16:11
  • You are correct that I missed the "how" and misread the question. Thank you. That said, the last line of my answer stands. Commented Oct 5, 2021 at 13:30

Their concerns are, that during pre-planning developers do not have too much time to understand a task that have not investigated themselves, so making suggestions and point estimating is difficult. So in fewer words, there is not enough time to understand a task and provide valuable feedback.

I am interested in the assumption that the only way to provide value during refinement and estimation is making statements (suggestions or feedback). In my experience, the most valuable contributions prior to team estimation is asking questions.

Asking questions can surface potential complexities, interactions, and dependencies that can increase scope. Answering those questions can do the same. The resulting discussion can be collaborative and engaging, and all of that is good for crosstraining.

You might want to try Planning Poker with the team.

In terms of repetitive work, I suggest moving to relative sizing (ie, find a previous similar task and give it the same size), which shouldn't take much time.


Another simple strategy that I often use is to mention in meetings the things that are probably going to concern them in the near future, and I ask them to begin looking into those things well in advance, and that we will discuss them soon. We're always looking several sprints into the future. "Forewarned is forearmed."

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.