3 ms·

When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with or

When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working? Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's easy to just look at the huge lists of tasks and think "Well, I'm expected to take a year to complete all these, and during that time, more work will be added to the pile, so I can just take my time" and become complacent. That all said, sprint planning is impossible to get perfect, especially with an incompetent manager that fails to recognize patterns in point assignments. Consistent underestimations on the number of points the tasks are can look like people are underperforming. Consistent overestimations look like you have a team of rock stars.

jwestbury 3y ago
> 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?
cliff_badger 3y ago
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?"
- xwdv 3y ago
  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.
  - icedchai 3y ago
    If you finish your 8 point story in a day, you should pace your work better. ;)
  - JohnBooty 3y ago
    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.
- Sohcahtoa82 3y ago
  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.
- icedchai 3y ago
  Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.
2023throwawayy 3y ago
> 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.
- icedchai 3y ago
  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.)
  - Lutger 3y ago
    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.
    - icedchai 3y ago
      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!

jwestbury 3y ago

> 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?

cliff_badger 3y ago

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?"

xwdv 3y ago
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.
- icedchai 3y ago
  If you finish your 8 point story in a day, you should pace your work better. ;)
- JohnBooty 3y ago
  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.
Sohcahtoa82 3y ago
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.
icedchai 3y ago
Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.

2023throwawayy 3y ago

> 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.

icedchai 3y ago
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.)
- Lutger 3y ago
  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.
  - icedchai 3y ago
    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!