User Story Time Constraints

Question

My team has been trying to switch to Agile recently. The line manager has been taking 1-2 days per user story as a hard limit rather than a guideline, and framing it as a failure of the developer if the time limit is not met. I am not sure if that should be the case since there are a lot of unknowns and possible blockers while implementing a story, or the story might not be broken down properly at the beginning. I think part of it has to do with being stuck in a Waterfall mindset so reviewing and adjusting requirements is not a solution.

What is a good way I can communicate this is causing unnecessary stress? What should I propose as an alternative?

Answer 1

First, the Scrum Guide is fairly clear about this behavior being wrong. The development team and only the development team owns that. (Since you are referring to SAFe in your tag, I'm assuming you are also using the Scrum Guide) This is unlikely to deter him, but it's something to look at if he feels like this is following the rules (which is completely possible. He may just have a misunderstanding).

Past that, you may want to try seeing why he's doing it. Is it a misunderstanding? Is there pressure from somewhere else? Maybe he's trying to help the team to accomplish something but that isn't coming through in his message. For example, he may be trying to introduce a constraint to get the team to break down work smaller.

Once you understand his point of view, the next steps will be easier to identify. Personally, I usually share with leaders that they need to be careful about rules and metrics. If a team member thinks that their own success is best served by meeting a metric at the expense of something else, like code quality, the leader could be accidentally creating a huge problem, even if his intentions are good.

Answer 2

The central part of agile software development is the self-organizing team.

The development team, and only the development team, determines how sprint work is completed. No member of the development team should report to another member of the team.

Any interference by outsiders (a manager in your case) should be blocked by the scrum master or product owner. If the manager is a stakeholder in the product, then there is a well-defined process for adding stories to the backlog and reviewing completed work.

You can't say you are "agile" when you have to work within artificial constraints. If your manager is not familiar with the Scrum guide, then I would post some of the key points on the wall as a constant reminder of what you are striving toward and why.

Answer 3

Seems to me that you need a Scrum Master. Agile teams are self-organized, and any estimation should be agreed upon by the team, and not one person, specially not a 'project manager'.

Remember that the idea is not to do "good" estimations, but to do "consistent" estimations. This means that if you give a certain story the value of 3, other similar stories should have a similar value. And keep in mind that this values have NO correlation with time; so if for a team 1 is equal to a day (or 8 hours), this same value could mean 16 or 4 hours to other teams. As your sprints come and go, this estimations should get more and more "precise".

Estimations have always been hard in software development, and I think your manager either lacks (good) experience in this particular area, or thinks that pressure and reprimands work to improve development time (hint: they don't).

On the topic of how to communicate it: Probably in a retrospective ceremony, always start with something positive.

PD: Here's some info on planning poker: https://en.wikipedia.org/wiki/Planning_poker

Answer 4

There are already lots of interesting answers here, that refer to scrum and agile.

However, you aren't referring to a product owner, nor to a scrum master but to a project manager. So I'll provide you some complementary arguments.

• The success of a project depends entirely on the performance of a team as a whole. Blaming individuals will not improve the team cohesion. What will happen with blame and shame ? Everybody will start to worry for his/her own agenda in order not to get blamed, and then all the benefits of a constructive team dynamic will get lost.

• Can your manager guarantee that all user stories are feasible within the 1-2 days ? If he/she can't, how could he/she blame the developer for taking longer ?

• Intuitively, I'd say that your project manager should first follow an agile training and make a mantra out of the agile manifesto before claiming being agile. But you can't tell that so bluntly unless you already have another job in sight ;-). So ask your manager to organise a meeting for the last of the 12 principles:

  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  Before the event, agree with your teammates that collaborative estimating of the stories is THE thing to put through. During the event, propose the scrum way. But be open: don't isolate the manager; suggest that PM assists to the estimation so that he/she can advise the team if necessary. This should reinsure him/her. Maybe even ask him/her to explain planning poker or similar methods at the first session (well, obviously he/she doesn't know, but this will force your manager to learn about it). If your manager is reluctant, propose the new approach as an experiment, for the next couple of sprints. I'm pretty sure that witnessing your team making collaborative estimates, exchanging founded technical arguments to plan the sprint will help the project manager to realise the benefit of the approach.