4 ms·

Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and us

Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it. As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.

ch4s3 4y ago
> We story pointed and those metrics were only ever seen and used by us That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? > but I do take light exception when people shit on it an go on to describe a process that is alien to me Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off. It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.
- sodapopcan 4y ago
  That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about. I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want. Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.
  - ch4s3 4y ago
    Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.
- JamesBarney 4y ago
  There another issue I've seen with all the forced estimation that gives questionable values to the business. When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.
  - ch4s3 4y ago
    I think it also incidentally discourages the trade off conversation by artificially time boxing work.
- vlovich123 4y ago
  We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.
  - ch4s3 4y ago
    That’s not entirely unreasonable but also not the prescribed method I’m criticizing.
    - vlovich123 4y ago
      I get that. In general I find scrum/agile to be unhelpful when run by people who don’t adapt it to the team/business needs.
      - deleted 4y ago
        [deleted]
- dfcowell 4y ago
  > what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? This sounds counter-intuitive, but I’ve found in many teams the value of story pointing is to instigate healthy conversations about requirements and surface assumptions in a team that might be reticent to engage in those kinds of conversations naturally. The actual point values are probably the least important outcome - any inaccuracies tend to average out over time anyway. I’ve gone in to many teams in my career where “planning” amounts to 1-liner tickets describing a month’s worth of work, and the team has a few dozen of these in the backlog. Conversations about what is actually involved in delivery don’t happen, and execution is chaotic because everyone has a different understanding about what we’re building. This sounds like a dysfunctional team because it is. A surprising number of teams are dysfunctional, and many of these frameworks and tools come out of attempts to solve for dysfunction. In these teams trust and morale tends to be low. The abstraction of story points (and associating them with complexity, not time) opens the door to having conversations about what the work actually is rather than how long everyone will take to do it. It’s a lot easier to hear “why do you think this is a 5-pointer instead of a 3-pointer” instead of “why do you think this will take 5 weeks, I think it should only take 3.” Scrum isn’t a universally-applicable tool, and introducing story points without also leveraging their ability to stimulate conversations about the work is a waste of time, but applied well they can help break through to teams that aren’t ready (or don’t have the muscle memory,) to have these conversations without some kind of trigger.
  - shostack 4y ago
    Having been in a team that needed to have these conversations because many were ramping up on the work, these conversations were godsends for catching inaccurate and problematic assumptions, making sure people understood how their work supported the business, and enforcing consistency with how the work was organized and documented which helped as the team grew and turned over.
- dhzhzjsbevs 4y ago
  > what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? My team asked for this. I dont know why they need it but apparently it helps them understand how much work theyre agreeing (and committing to shipping) in a sprint. I think if you have a good grasp on what each issue will entail, you dont really need it but if youre less experienced maybe it helps?
  - ch4s3 4y ago
    But that just begs the question, why sprint? Two weeks seems arbitrary, and meetings on that cadence are pretty noisy. Trying to deliver in that frame can either lead to dead time if things go faster than expected or can lead to artificial failures if you miss it. Why set yourself up to fail that particular way? I don’t think it’s especially useful for organization or accountability and adds a lot of noise and waste.
    - dhzhzjsbevs 4y ago
      Of course its arbitrary, but you gotta pick something. We optimise for progression. Failing a sprint doesn't actually have any real ramifications. What we use failure for is a signal to indicate problems. Missed? I guess we have some talking to do in retro to figure out what was misunderstood. Missed three sprints in a row? Is there a problem we need to resolve? Similar to misses, we don't really get much from shipping on that cadence either, other than progress and building confidence in upper management to base their timelines on us delivering what we expect.

ch4s3 4y ago

> We story pointed and those metrics were only ever seen and used by us That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? > but I do take light exception when people shit on it an go on to describe a process that is alien to me Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off. It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.

sodapopcan 4y ago
That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about. I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want. Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.
- ch4s3 4y ago
  Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.
JamesBarney 4y ago
There another issue I've seen with all the forced estimation that gives questionable values to the business. When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.
- ch4s3 4y ago
  I think it also incidentally discourages the trade off conversation by artificially time boxing work.
vlovich123 4y ago
We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.
- ch4s3 4y ago
  That’s not entirely unreasonable but also not the prescribed method I’m criticizing.
  - vlovich123 4y ago
    I get that. In general I find scrum/agile to be unhelpful when run by people who don’t adapt it to the team/business needs.
    - deleted 4y ago
      [deleted]
dfcowell 4y ago
> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? This sounds counter-intuitive, but I’ve found in many teams the value of story pointing is to instigate healthy conversations about requirements and surface assumptions in a team that might be reticent to engage in those kinds of conversations naturally. The actual point values are probably the least important outcome - any inaccuracies tend to average out over time anyway. I’ve gone in to many teams in my career where “planning” amounts to 1-liner tickets describing a month’s worth of work, and the team has a few dozen of these in the backlog. Conversations about what is actually involved in delivery don’t happen, and execution is chaotic because everyone has a different understanding about what we’re building. This sounds like a dysfunctional team because it is. A surprising number of teams are dysfunctional, and many of these frameworks and tools come out of attempts to solve for dysfunction. In these teams trust and morale tends to be low. The abstraction of story points (and associating them with complexity, not time) opens the door to having conversations about what the work actually is rather than how long everyone will take to do it. It’s a lot easier to hear “why do you think this is a 5-pointer instead of a 3-pointer” instead of “why do you think this will take 5 weeks, I think it should only take 3.” Scrum isn’t a universally-applicable tool, and introducing story points without also leveraging their ability to stimulate conversations about the work is a waste of time, but applied well they can help break through to teams that aren’t ready (or don’t have the muscle memory,) to have these conversations without some kind of trigger.
- shostack 4y ago
  Having been in a team that needed to have these conversations because many were ramping up on the work, these conversations were godsends for catching inaccurate and problematic assumptions, making sure people understood how their work supported the business, and enforcing consistency with how the work was organized and documented which helped as the team grew and turned over.
dhzhzjsbevs 4y ago
> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? My team asked for this. I dont know why they need it but apparently it helps them understand how much work theyre agreeing (and committing to shipping) in a sprint. I think if you have a good grasp on what each issue will entail, you dont really need it but if youre less experienced maybe it helps?
- ch4s3 4y ago
  But that just begs the question, why sprint? Two weeks seems arbitrary, and meetings on that cadence are pretty noisy. Trying to deliver in that frame can either lead to dead time if things go faster than expected or can lead to artificial failures if you miss it. Why set yourself up to fail that particular way? I don’t think it’s especially useful for organization or accountability and adds a lot of noise and waste.
  - dhzhzjsbevs 4y ago
    Of course its arbitrary, but you gotta pick something. We optimise for progression. Failing a sprint doesn't actually have any real ramifications. What we use failure for is a signal to indicate problems. Missed? I guess we have some talking to do in retro to figure out what was misunderstood. Missed three sprints in a row? Is there a problem we need to resolve? Similar to misses, we don't really get much from shipping on that cadence either, other than progress and building confidence in upper management to base their timelines on us delivering what we expect.