-1

We are supposed to follow agile approach in my team.We have a Scrum master, Product owner, proxy product owner and team of devs, I am a dev.

During Poker, we need to make estimations on developpement tasks. From what I know about Agile, only devs can give estimations, in our case, Scrum master and Product owner want us to follow their estimations (they have some pression with clients) so when we estimate a task to 5 days, they do not like it, even if we have explainations why 5. And in general (99% of time) they ask re-estimation and kind of "force" us to change our estimation to 2.

The worst part is that they even do not know what they are talking about, sometimes we even have half of specifications !

My question is : According to Agile, is it true that Dev tasks estimation are done only by devs, right ?

Herb
  • 636
  • 1
  • 15
  • 29
BestAboutMe
  • 127
  • 4
  • This _might_ be a better fit for softwareengineering or theworkplace. That being said, I would agree that estimates can only fairly come from those doing the work - otherwise you fall foul of the pig & chicken problem (a pig and a chicken agree to make a breakfast. "Great!" the chicken says, "you bring the bacon, I'll bring the eggs".) – Jimmy Breck-McKye Oct 11 '18 at 12:56
  • 1
    Anybody contributing to the body of work contributes to the estimate. For example, a developer may say that changing the wording on a page is a trivial body of work and may estimate it at only minutes of effort. But the product owner may foresee a lot of meetings and back-and-forth with business ownership and legal counsel to define the text. Overall, the body of work is large even though the development effort is small. Now, having said that, what you're describing is not agile. Or even professional behavior. It's just people making demands. – David Oct 11 '18 at 12:57
  • 1
    As a side note about agile... When you say "sometimes we even have half of specifications" that's perfectly reasonable and common. What *is* agile is accepting the fact that estimates are being made based on information that is known to be incomplete. As more information becomes known, estimates can change. – David Oct 11 '18 at 13:00
  • I'm voting to close this question as off-topic because it's about software development methodologies, not programming. – EJoshuaS - Stand with Ukraine Jun 05 '19 at 22:08

3 Answers3

3

You are right. The scrum master's role is there to facilitate the meeting, not take part in the meeting by estimating. You are correct. Estimation is only done by the dev team.

Instead of arguing with agile principles I would do a more constructive way to approach this by writing down two estimates: the dev team's estimation and the other estimation by the scrum master and product owner and when the ticket is done look at how much time it actually took. There can be learnings in there for the dev team as well, but much more learning for your scrum master and the product owner.

Sounds like a lot of pressure.

Christoph Eicke
  • 1,134
  • 7
  • 15
  • Don't know why there was a downvote on this answer. It answers the question (and correctly) and then provides some extra advise. Good answer. – Daniel Oct 11 '18 at 19:56
1

According to Scrum the final estimate is made by people who do the work:

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

https://www.scrumguides.org/scrum-guide.html#events-planning

Maybe point your Scrum Master to the Scrum guide ;-)

The nice thing of work is it takes the amount of time it takes, doesn't really matter if it is a 2 or a 5. If they influence all the work the same you probably will have a stable velocity. Just don't take days estimates as how many days the work will take, suggested is to estimate in relative sizes, not days.

Niels van Reijmersdal
  • 2,038
  • 1
  • 20
  • 36
-1

My question is : According to Agile, is it true that Dev tasks estimation are done only by devs, right ?

If you go to the literature of classic scrum the scrum planning meeting is cleft in half (by a mighty sword).

During first half the product owner presents backlog items for the team which are candidates for the upcoming sprint. The backlog items already have estimates on them (in story points) produced by the whole team (not only the product owner) during the refinement/backlog grooming meeting. The team decides on how much work to commit to by looking at velocity from previous sprints and by consulting their gut feeling.

During the second half of the of the meeting the team breaks down the backlog items into tasks and, when appropriate, sets estimation of time of respective task.

If this is a good process or not is very context specific, so I leave it to you to decide...

The purpose of estimation is to get a good prognoses of scoop for future releases. It's a tool for the product owner when prioritizing and for managing expectation towards the stakeholders. If your PO thinks he/she can get more features by manipulating the estimates, they are up for a surprise down the line.

FatAlbert
  • 4,890
  • 6
  • 22
  • 34