9

During the daily standup meeting in the middle of a sprint, the de facto project manager/scrum master usually asks developers some version of:

"So when will this be done by?"

"So can you commit do having this task done by 4pm today?"

"How many hours do you have left on this subtask?"

This is frankly very annoying and doesn't make things get done any faster. The result is developers often feel under a lot of pressure and standups often feel more like a battleground than a collaboration.

As a developer, what's a solid way to handle this?

5

9 Answers 9

6

Best way to handle “So, when will this be done by?”

"At the end of the sprint".

I realize that's a snarky answer, but there's some truth hidden in there. It depends on who is doing the asking and why they are asking that question.

The project manager really has no business asking such questions -- they should ask the scrum master if they need detailed information about in-progress tasks, and they should do so outside of the daily stand-up.

If it's the scrum master who is asking, perhaps they are asking so that they can be prepared for upcoming road blocks. If that's the case, just be honest.

In scrum, the team is under no obligation to finish any particular task or story until the end of the sprint, assuming they are asking about a story related to the current sprint (versus an out-of-band hot fix). Deadlines for tasks within a story are owned by the team, and they shouldn't feel pressure from a project manager.

However, software development is a collaborative process so it's reasonable to accommodate such questions, within reason.

The solution? From your perspective: answer as honestly as you can, as briefly as you can if it's during the stand-up. If you're actively working on the task being asked about, you can always say something along the lines of "it's estimated to take a couple hours, so I might be able to finish it today". If you aren't working on it, a simple "I don't know, I haven't started working on it. I think the estimate still seems fairly accurate".

From their perspective: they need to accept your answer.

"So can you commit do having this task done by 4pm today?"

The answer to that should almost always be "no". There's simply no need to commit to an end-of-day deliverable for a task in the middle of a sprint. Whether the task is finished at 4pm today or 9am tomorrow is irrelevant as long as the story as a whole is finished by the end of the sprint.

"How many hours do you have left on this subtask?"

That's a reasonable question to ask. Just answer honestly. I realize that that's very hard to do. I've been there. I think developers are inherently optimistic. We'll look at a task and think "that'll only take me a couple hours" and before you know it the whole day has passed. That's why agile works -- we admit our limitations in estimating, and do our best to break things down into the smallest chunks possible.

3

Ask you Scrum Master to clarify, the purpose of a Sprint and Stand Up Meeting. Almost anyone working with Scrum would say the purpose of a Sprint is to decide what gets done during the length of the Sprint and I've never heard of anything being due during a sprint.

Maybe you have emergencies to attend to that really have nothing to do with a sprint. Teams/developers who have these duties outside of the sprint, need to make sure they're not including the time to do this as part of the sprint planning. Maybe you have an 8hr workday, but if you're spending 1-2 hours putting out fires, you can't expect to include that as part of the estimate.

As far as standup meetings go, you may want to suggest some other system to track when certain immediate tasks are going to get done like some sort of support ticket system. These shouldn't even be discussed during the standup.

Seems like your scrum master either needs to be retrained or rethink why you're doing Scrum in the first place. It's not a fit for all groups and situations. Someone at the top has not bought into it.

2
  • "the purpose of a Sprint is to decide what gets done during the length of the Sprint": And even this goal may not be reached because of wrong estimations, e.g. when extra implementation details become clear during implementation itself.
    – Giorgio
    Jun 19, 2017 at 17:19
  • @Giorgio - I'd say the purpose of a sprint is to decide what you "attempt" to get done. If you fall short, use that to plan the next sprint. That's the benefit of an iterative process. if it is a total failure, just scrap the sprint and start a new one. There's nothing to be gained for future planning when you've made a drastic miscalculation other than don't make the same mistake.
    – JeffO
    Jun 21, 2017 at 15:22
2

I have experienced micro-managing like this and the way I have successfully handled it is by being very transparent and communicative. It doesn't take long to gain the manager's confidence; you build trust and they back-off. Sometimes even giving you more space and latitude. Your manager may be feeling insecure or out of control so this goes towards easing that for them. Obviously it isn't ideal but you are a team and you should all want the same outcome. Good luck.

1
  • Empathy. That's a powerful skill not everybody masters :-). However, it's good to understand why the Manager puts so much emphasis on the planning, when in Agile, the emphasis is focused on the people. Understanding the pains of the Manager may help to conextualize the whys of the presure. However, the Manager and the company should be aware of estimations are just that. Assumptions. Not math, so they should practice empathy too towards the developers and give them credit.
    – Laiv
    Jun 19, 2017 at 21:07
1

"It will be done when it gets done."

There is no value in trying to get estimates of completion from developers. Estimates are inaccurate, especially if they are time based. In addition, people in managerial roles have a tendency to interpret those estimates as commitments, resulting in the damaging effects your developers are feeling.

One option would be to avoid answering the question in terms of time commitments.

"This task will be done after I do things A, B, and C."

"Okay. And how long will that take?"

"We'll see at the end of the day."

Changing the conversation from time commitments to what needs to be done can help take the edge and show that "how long it will take to get done" is less important than "what does it take to get done."

2
  • 2
    I agree that it's generally useless to provide estimates down to the hour, especially for something creative like programming that requires large amounts of uninterrupted work. But other people legitimately need to know when we will be ready, so estimates are necessary on a scale of days or weeks. If “scrum” gets in the way of that, then scrum and not the estimate is the problem. The good news: estimates get better as you practice them, and can be hedged: “there's a 50–50 chance I'm ready today, otherwise tomorrow morning”. I've also had good experiences with techniques like planning poker.
    – amon
    Jun 17, 2017 at 8:11
  • I agree that estimates can be of use for people outside the team, but my answer was specific to the OP's question on how to deal with micro management during standups.
    – binskits
    Jun 19, 2017 at 11:38
1

Don't be intimidated by the scrum master. Speak openly and frankly about the work ahead. Ask questions of her/him like what is the urgency. Why does it have to be done by 4? If it really needs to be done other tasks may need to be pushed till later. It's you opportunity to build truss. Frank answers are better early rather than excuses later.

1

The more "micro" the management is, the harder it is to make accurate prediction. If I have 20 eight hour tasks, that is tasks that are reasonably estimated to take eight hours each, that should be done in four weeks, or maybe a few days more or less. If I have one such task, there is a lot more variability.

Such a task may take 10 minutes if the problem to be solved turns out to be much easier than I thought. (Has happened to me, I estimated that I needed to write quite a lot of code, and it turned out someone else had already written exactly what I needed). Or it might take a week (my code doesn't work because of a bug in a library that needs to be fixed which then has all kind of evil consequences). For twenty tasks, these things balance out. Not for one task.

Someone is asking you to predict the future. You can't do that. And asked for predicting a single event, statistics doesn't help you. The kind of person asking these questions doesn't understand the meaning of "estimate" So if you are asked "will this be done in four hours", the possible answers are "very likely", "maybe, maybe not" and "very unlikely".

1

This is a good question. I'll answer from the perspective of someone with 30 years experience with a decade as a dedicated project manager in all areas except software development but recently stumbled into the area software development unintentionally. Regardless of the methodology being used across your team and what it is called, at the end of the day development projects are the same as any other in the business sense that objectives are to be met within competing constraints of time, budget, and quality -- and while projects execute the business continues to move and evolve and has a good chance of injecting changes into your project. Therefore, it is necessary to set and commit to objectives and timeframes and to be able to provide updates on a frequent basis and when asked. I don't recommend the answer to queries be some form of "if you ask that question it shows your ignorance and you need to be trained".

That being said, in my experience what makes time estimations in software development particularly challenging is that development projects entail a lot of unchartered territories. The technical definition of a "project", according to the Project Management Institute's Project Management Body of Knowledge, is that a project must be unique. Yet, the far majority of "projects" in IT are mere re-executions of previously devised blueprints & designs and implementation run books. In software development, we have frameworks and various genericized design patterns that make a lot of the development re-usable but still, the core of each project is completely unique.

In addition, most development projects entail integrating with other systems and how quickly that can be done is a big guess. I am working on a project right now that my original time estimates were based on the assumption that the 4 systems that I need to interact with programmatically would have API's, and it turns out none do. In addition, one of the systems is cloud hosted, and my organization has policies that prohibit the work being done. Who could've predicted that?

As discoveries are made that put timeframes in jeopardy it is important to well communicate why the delay has arisen, why it couldn't be foreseen, etc.

I've also been through being told the timeframe given wouldn't work and make it happen much "quicker". Another variation is being given a boat load of changes to inject into the development without also being afforded the additional time. There is a law in physics that says matter cannot be created or destroyed, and this comes to mind because it seems to me that time cannot be created out of thin air either. Accelerating the development will likely have a negative impact on the release quality, the supportability of the product, and/or the future evolving of the product.

Requests about the schedule should be answered in general business terms. "Yes, we are on track to meet the timeframes previously committed, and there are no issues brewing that put that in jeopardy". Requests to add significant scope without more time, or to simply accelerate delivery, should be some form of "we can do that, but just so all are aware that inherently carries risk of bugs because much of the development time is done to be proactive so as to not introduce bugs and also to test comprehensively." When they respond with "so just test faster", that gets a response that explains development testing does not entail idle time and can be accelerated without introducing some risk of missing defects.

In summary, I am simply suggesting that all developers -- not just the leads, scrum master, or project manager, be prepared to discuss their tasks in a business context and to have discussions on changing project parameters by making aware the trade-offs that would result.

1
  • This is an intimidating answer. It's not until the sixth paragraph that I see something resembling an actionable answer, and I almost quit reading before I got there. You might want to consider rewriting it to lead with the final answer ("Requests about the schedule should be answered in general business terms"), and then follow with the explanation. Jun 19, 2017 at 18:14
0

As work is performed or completed, the estimated remaining work is updated.

-- Scrum guide, page 15

Each developer should be updating their task status and estimated remaining hours each and every day in whatever productivity tool your team uses (e.g. TFS).

So the simple answer to your manager is to direct him to the "hours remaining" column on the task list. Hopefully he will learn that he can access these numbers himself and stop asking stupid questions.

2
  • 1
    The Scrum guide says nothing about how the work is estimated. It could very well be that the work is broken down into tasks and that the update is based on task completion and tasks remaining. Jun 16, 2017 at 23:21
  • If a task is divided into several subtasks, the scrum master should still be able to see how the current estimations are.
    – mhr
    Jun 19, 2017 at 11:31
0

By asking any of the above questions.What the scrum master is trying to decide is are we on track for this sprint and Whether there are any blocking issues for you to be able to compete this task.

Story points do not correlate with man hours, they are not meant to, but by asking if you can do something by a date he is really asking what's stopping you from competing this task ? If you need something ask, in my view his role is to make sure you are able to compete the sprint, that is what he is really asking....

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