4 ms·

Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our

Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new. The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts). You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.

holistio 3y ago
I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.
knodi123 3y ago
Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.
dopidopHN 3y ago
I had a team with a shadow backlog. Fun times
foogazi 3y ago
> Our team gets publicly dinged if we "carry over" tickets between sprints This is not part of scrum
- jatins 3y ago
  You'd be surprised at how many places this is. At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint! [0] Just writing that sentence makes my eye twitch
  - ncann 3y ago
    Similarly, in order to fit stories into a sprint and not spillover, there is the constant fixation on making stories "as small as possible". So now people make a story for adding a button, then another story for the click handler of the button, then another story for saving data into DB when button is clicked, then another story for adding the tests, and so on. Then the sheer amount of time talking about how to split that up and adding all those into JIRA...
- hiyer 3y ago
  It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either: 1. The team is not breaking down tasks granularly enough, or 2. They're not estimating tasks correctly Practically, it means nothing of course.
  - foogazi 3y ago
    In Scrum: - the product owner sets the backlog priority - team estimates - team commits to what it can deliver from the backlog - any misses are analyzed for scope mistakes Rinse/repeat There’s no shaming part Edit: format
    - seadan83 3y ago
      The scrum guide [1] says team gives a forecast and not a commitment. I have yet to know any other scrum practitioners aware of that update. Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment. The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment" [1] https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast *edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
Camisa 3y ago
Great time to tackle some tech debt
- marcus_holmes 3y ago
  Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.
  - kuchenbecker 3y ago
    Do it anyway, file the ticket and pull it into the next sprint.
    - marcus_holmes 3y ago
      So stop following Scrum? Completely agree
  - bombolo 3y ago
    Ah yeah I had a boss that wanted me to open tickets, estimate them, plan them, do them, to fix 1 line issues that I would randomly find working on other tasks. Normally I just fix them within a separate commit.
hereforcomments 3y ago
I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.
marcus_holmes 3y ago
This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?). It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything. We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work. Such a waste of time and talent.
- tamimio 3y ago
  > I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything. That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
- some_guy_in_ca 3y ago
  As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.

holistio 3y ago

I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.

knodi123 3y ago

Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.

dopidopHN 3y ago

I had a team with a shadow backlog. Fun times

foogazi 3y ago

> Our team gets publicly dinged if we "carry over" tickets between sprints This is not part of scrum

jatins 3y ago
You'd be surprised at how many places this is. At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint! [0] Just writing that sentence makes my eye twitch
- ncann 3y ago
  Similarly, in order to fit stories into a sprint and not spillover, there is the constant fixation on making stories "as small as possible". So now people make a story for adding a button, then another story for the click handler of the button, then another story for saving data into DB when button is clicked, then another story for adding the tests, and so on. Then the sheer amount of time talking about how to split that up and adding all those into JIRA...
hiyer 3y ago
It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either: 1. The team is not breaking down tasks granularly enough, or 2. They're not estimating tasks correctly Practically, it means nothing of course.
- foogazi 3y ago
  In Scrum: - the product owner sets the backlog priority - team estimates - team commits to what it can deliver from the backlog - any misses are analyzed for scope mistakes Rinse/repeat There’s no shaming part Edit: format
  - seadan83 3y ago
    The scrum guide [1] says team gives a forecast and not a commitment. I have yet to know any other scrum practitioners aware of that update. Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment. The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment" [1] https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast *edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.

Camisa 3y ago

Great time to tackle some tech debt

marcus_holmes 3y ago
Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.
- kuchenbecker 3y ago
  Do it anyway, file the ticket and pull it into the next sprint.
  - marcus_holmes 3y ago
    So stop following Scrum? Completely agree
- bombolo 3y ago
  Ah yeah I had a boss that wanted me to open tickets, estimate them, plan them, do them, to fix 1 line issues that I would randomly find working on other tasks. Normally I just fix them within a separate commit.

hereforcomments 3y ago

I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.

marcus_holmes 3y ago

This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?). It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything. We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work. Such a waste of time and talent.

tamimio 3y ago
> I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything. That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
some_guy_in_ca 3y ago
As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.