4 ms·

> If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating

> If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating work in the next sprint. You don't even "fail" the sprint, that's a bad attitude. You just consider work spilled over and take on less work + spillover work next sprint. There's only cause for concern if you repeatedly have spillovers every sprint - that's usually mostly a manager issue, and sometimes IC's. Ideally you only have spillovers because of things that were not under your control - power outages, 3rd party vendor outages, etc.

lionkor 3y ago
Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet
- zerbinxx 3y ago
  There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done. As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing. The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.
  - rgblambda 3y ago
    > First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?". Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job. But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.
    - zerbinxx 3y ago
      Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day. If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.
  - lamontcg 3y ago
    Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.
    - zerbinxx 3y ago
      Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.
      - 3y ago
- Cthulhu_ 3y ago
  Whichever the reason: you don't use negative language. You didn't fail the sprint, you didn't have bad developers; you sit down and discuss what you can do better next time, for example: reduce your commitment, spend more time refining and preparing a story before estimating it, take up courses / do knowledge sharing, etc. You never use language like "the sprint failed" or "what went wrong", you say "we underestimated", "there were unforseen circumstances", or "what can we do better". I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. "We failed" is giving up, "what can we improve" is taking ownership and action.
  - antisthenes 3y ago
    > I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. I think it's less about the language and more about being forward looking. You can't change what happened in the sprint, but you can do the next sprint better. It's also about clear separation between identifying issues vs assigning blame. The latter doesn't help anyone, because blame is almost always backward-looking.

lionkor 3y ago

Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet

zerbinxx 3y ago
There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done. As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing. The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.
- rgblambda 3y ago
  > First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?". Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job. But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.
  - zerbinxx 3y ago
    Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day. If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.
- lamontcg 3y ago
  Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.
  - zerbinxx 3y ago
    Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.
    - 3y ago
Cthulhu_ 3y ago
Whichever the reason: you don't use negative language. You didn't fail the sprint, you didn't have bad developers; you sit down and discuss what you can do better next time, for example: reduce your commitment, spend more time refining and preparing a story before estimating it, take up courses / do knowledge sharing, etc. You never use language like "the sprint failed" or "what went wrong", you say "we underestimated", "there were unforseen circumstances", or "what can we do better". I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. "We failed" is giving up, "what can we improve" is taking ownership and action.
- antisthenes 3y ago
  > I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. I think it's less about the language and more about being forward looking. You can't change what happened in the sprint, but you can do the next sprint better. It's also about clear separation between identifying issues vs assigning blame. The latter doesn't help anyone, because blame is almost always backward-looking.