5 ms·

> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force

by xedrac 5y ago

> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game the system by over estimating every task are viewed as super achievers, even if their actual value contribution is far lower. I think if you take away the metrics aspect of sprints, it actually becomes more useful.

onlyrealcuzzo 5y ago
At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...
- ignoramous 5y ago
  > Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?
  - onlyrealcuzzo 5y ago
    Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up. Is that something that should've been caught in integration tests? Why did it pass review then? As long as it's not a pattern, it's not a problem. If something super severe happens - that's an organization-wide problem...
- strzibny 5y ago
  That sounds like a horrible place to work!
- pvorb 5y ago
  The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
  - thesimon 5y ago
    We usually start by discussing the outliers on both sides. This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
    - pvorb 5y ago
      Yes, that's exactly what I meant to describe.
- A_non_e-moose 5y ago
  > If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts. Which assumptions are behind that statement? Does the team have uniform experience working in a single product? That statement feels more applicable here. Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.
blackoil 5y ago
The problem with Sprints is that they come with fixed events and associated ceremonies. If your 2 week task is slipping by 2 days you have to answer why in the retrospective. If you remove the sprint deadlines and make the retrospective etc. adhoc and mostly dev team initiated it takes away all the pressure while keeping monitoring/measurements.
- sovietmudkipz 5y ago
  That system of ad hoc meetings probably works for a team who works well together. Any system can work for a team that works well together. My team tried ad hoc meetings. We wound up not having the meetings. We now just stick to the sprint schedule, at the behest of our manager.
andruby 5y ago
That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing. Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed. [0] http://pokershirt.io http://pokershirt.io
- scottlilly 5y ago
  I'm also a fan of using Kanban for most corporate line-of-business development. In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum. At the end of the iteration, they have a unfinished tasks and one of two things happens. The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up). Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close. They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem. And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality. Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.
  - icedchai 5y ago
    I have seen much of these problems with Scrum, as well. Redefining "complete" so we can book the points, but actually finish it in the next sprint is very, very common. Finishing early, starting on a future story, but the scrum master asking you to not bring that story into the current sprint, in case you don't finish it, is also a frequent occurrence. My view is "if I don't finish it, it rolls over, so who cares", but this is frowned upon since it throws off the reports.
jadeforrest 5y ago
Hi, I'm the author. This isn't a post about scrum vs kanban. It's primarily about the value of using a specific definition of milestone to encourage incremental delivery. And to highlight some of the benefits of delivering in this way.

by xedrac 5y ago

onlyrealcuzzo 5y ago

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

ignoramous 5y ago
> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?
- onlyrealcuzzo 5y ago
  Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up. Is that something that should've been caught in integration tests? Why did it pass review then? As long as it's not a pattern, it's not a problem. If something super severe happens - that's an organization-wide problem...
strzibny 5y ago
That sounds like a horrible place to work!
pvorb 5y ago
The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
- thesimon 5y ago
  We usually start by discussing the outliers on both sides. This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
  - pvorb 5y ago
    Yes, that's exactly what I meant to describe.
A_non_e-moose 5y ago
> If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts. Which assumptions are behind that statement? Does the team have uniform experience working in a single product? That statement feels more applicable here. Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.

blackoil 5y ago

The problem with Sprints is that they come with fixed events and associated ceremonies. If your 2 week task is slipping by 2 days you have to answer why in the retrospective. If you remove the sprint deadlines and make the retrospective etc. adhoc and mostly dev team initiated it takes away all the pressure while keeping monitoring/measurements.

sovietmudkipz 5y ago
That system of ad hoc meetings probably works for a team who works well together. Any system can work for a team that works well together. My team tried ad hoc meetings. We wound up not having the meetings. We now just stick to the sprint schedule, at the behest of our manager.

andruby 5y ago

That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing. Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed. [0] http://pokershirt.io http://pokershirt.io

scottlilly 5y ago
I'm also a fan of using Kanban for most corporate line-of-business development. In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum. At the end of the iteration, they have a unfinished tasks and one of two things happens. The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up). Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close. They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem. And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality. Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.
- icedchai 5y ago
  I have seen much of these problems with Scrum, as well. Redefining "complete" so we can book the points, but actually finish it in the next sprint is very, very common. Finishing early, starting on a future story, but the scrum master asking you to not bring that story into the current sprint, in case you don't finish it, is also a frequent occurrence. My view is "if I don't finish it, it rolls over, so who cares", but this is frowned upon since it throws off the reports.

jadeforrest 5y ago

Hi, I'm the author. This isn't a post about scrum vs kanban. It's primarily about the value of using a specific definition of milestone to encourage incremental delivery. And to highlight some of the benefits of delivering in this way.