How to handle project manager getting upset when tasks spend multiple days in development?

Question

Our process is that developers create subtasks for user stories to track their work on that particular user story on the scrum board.

Good so far.

However, we have a de facto project manager attempting to "do agile" and take on the scrum master role. During the daily standup, he gets visibly upset when a subtask sits in the "In Development" column for longer than a day or two. He claims that developers should create subtasks that are equivalent to 4-8 hours of development time. This way, there should be subtasks moving across the board every time.

As a developer, I feel like trying to arbitrarily divide my work into 4-8 hour chunks and create a separate task for each just so he feels better when he looks at the scrum board:

1. makes no sense
2. wastes development time
3. creates unnecessary paperwork/busy work that bogs down the process

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

Answer 1

Four points....

1. Per Schwaber and Beedle, a Scrum task should take roughly 4 to 16 hours. Some complicated tasks can take longer if the team can't find a better way to break it down. So while your colleague is partly right, he is also partly wrong. Maybe buy him a copy of this book and ask him to read it (nicely).

2. The task breakdown (including estimated hours) should be reviewed during the sprint kickoff, and the scrum master should be present and aware of the hours associated with each task. If he has a problem with the length of a particular task, he should speak up then, and not later. Make sure to call his attention to the estimates during the kickoff.

3. Perception of progress should be managed by two things-- objectively, via burndown rate, and subjectively via demos. Not by watching tasks move across the board. If your sprints are longer than 2 weeks, it might make sense to schedule more demos, possibly weekly. If he can see progress via some other means, maybe he won't obsess so much over counting tasks.

4. Even if the task isn't completed, completed/remaining hours should be updated on a daily basis. So if your manager looks at total remaining hours instead of total remaining tasks, maybe that will be satisfactory.

Answer 2

Ask him "what is the value of sub-tasking my work into 4-8 chunks of time?" followed by "shouldn't our user stories be small enough that they don't need to be sub-tasked?"

Project managers attempting to "do Agile" tend to fall into this trap where they attach to the most mechanical parts of Scrum, typically things like timed tasks and sprint commitment, because they are the parts of Scrum most familiar to what they already know, which is command-and-control style management.

It sounds like this de facto manager needs some help with understanding the values and principles of Agile. Maybe pointing him to the Agile Manifesto.

Without a change in worldview, it isn't likely that this manager will be able to implement Scrum successfully.

Answer 3

Scrum, more than anything, is about culture, including the culture of the organization at large. Everyone has to buy into it, from the top down, for it to be successful. Given that, if the organization is fully behind Scrum, then some moves can be made to either better align this "manager" with the Scrum Master role, or to replace him with an actual Scrum Master. If the organization is not behind Scrum, then you're probably screwed to begin with.

Ultimately, the Scrum Master role is not a managerial role. The Scrum Master's job is to remove impediments to the development team getting PBIs done and ensuring that the ritual of Scrum is adhered to. That's it. In Scrum, the development team is responsible for setting their own goals, assigning work to sprints, and setting their cadence and velocity. All this is fundamentally misaligned with a traditional top-down management style.

All that said, there's two things to look at here. First, a task that spans multiple days is likely a sign that it should be broken up into smaller tasks. The only other reason it should take that long is if there's an impediment preventing it from being completed, which is then the job of the Scrum Master, and hence your current manager-type, to solve. If you have a valid reason why you cannot complete the task, it's your job to let the Scrum Master know, at the daily or sooner, and then its his or her job to fix it, so you can get on with your work. Honestly, though, in most situations a task large enough to take multiple days, and which couldn't be broken down into multiple tasks, would signal a PBI that's in fact too large to fit in a single sprint. You should manage these things accordingly.

Second, you ultimately may not have much power in this situation. If your manager is telling you to break the task down, break the task down. Whether it's a "Scrum" thing to do, is besides the point, because you're already not actually following Scrum by the fact that you have a manager dictating what you have to do. You can politely broach the issue and attempt explain why you don't think this is a good way to do things, but ultimately, what your managers says, goes, and you're going to have to live with that, or seek alternate employment.