Hacker News Reader

> slight sense of urgency

This is my biggest beef with agile. The urgency is false, stressful, and unnecessary.

If you're always in a "sprint" you're never actually sprinting. No one can sprint forever.

The urgency is often fake. You complete your sprint, only to find out you built a feature nobody needed any time soon (or maybe ever.)

This is my biggest beef with deadlines in general and sprints in particular. The urgency is fake, but the cost is not.

It is not 'free' to set a random deadline. You will pay with productivity and quality and cause stress. There is no way around it, so do it for a sound reason.

These days if somebody sets a deadline I always probe them to find out why. "What happens if we are a week late, a month? Is there a reason for that date?" This often annoys people, which reveals me they don't really know what they are doing and it is not actually a real deadline. Just something that people think that project management is.

99% percent of deadlines could be replaced with something like: "this feature is worth a ballpark of 2 to 5 weeks of the team to me. Can we make it? Keep me posted if it doesn't work out, I want to know so I can consider dropping it and pivoting to something else, even when we already invested 4 weeks in it."

That is a reasonably thing a manager can ask, and more often than not developers can actually answer this in a much more efficient way than detailing and monitoring a sprint plan.

I built something in one sprint, only to see it replaced with "V2" two sprints later. "V1" was never used by an actual end user. But, yeah, it worked for demos!

> We've got a backlog that will easily take us a year to complete.

To me, this is actually a great argument in favour of 2- to 4-week sprints. Long backlogs are psychologically demotivating. Finishing a task only to find that the backlog is just as long, or -- worse, and more likely -- longer than when you started is just so depressing.

Sprints give a small, subtle, but real psychological boost from routinely completing achievable workloads. It's when you overload sprints and can't possibly complete them that they start to break down. From a psychological perspective, you should usually complete all the tasks in a sprint. Not always -- but most of the time.

Of course, people who advocate for 6- to 8-week sprints also get this benefit, but, from my perspective, there's too much chance of having to change your plans partway through. The benefit of a shorter cycle is that it's easier to pivot everyone to work on something new. By way of example, my team at my previous employer was building a new service, and we discovered about halfway through that we had a design flaw that would prevent us from surfacing the level of detail we wanted for API errors. On 2-week sprints, we were able to use half of the next sprint to change our error handling across our entire code base. Sure, we could have done that anyway with longer sprints -- but then why bother having concrete plans at all, when you know they're likely to change?

Isn't the task itself time boxed by the points you assign to the story?

> "It is a 2 point story, why have you taken three weeks to complete it?"

This is only a guideline, don’t treat it like a hard rule. There could easily be good reasons why a 2 point story took three weeks.

Also gotta stop the negative bias. People will want to complain easily if your 2 point story takes you three weeks, but no one will be singing praises if your 5 or 8 point story is done in a day.

If you finish your 8 point story in a day, you should pace your work better. ;)

    There could easily be good reasons why a 2 point story took three weeks.

If it was because you were interrupted and given other priorities, that is totally valid.

If it was an estimation failure, that really needs to be looked at and learned from.

I find that this is typically a problem with management and/or process, not the engineer. We as an industry typically do not respect the time it takes for engineers to produce an accurate estimate. This time itself needs to be treated as a first-class concept and time needs to be allocated to it which, in practical terms, often means it needs its own task/card/story/ticket/whatever in the framework of one's choice.

There are nearly always unknowns (typically some kind of externality or legacy code) to explore before we really know how much time something will take.

My assumption was that if you're not performing sprints, you're not assigning points to stories either.

I don't know why I made that assumption.

Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.

Because sometimes you stumble on a graveyard and you end up cleaning out the corpses of developers past.

Beautifully put.