4 ms·

> First of all, what are story points? Are they measures of time it takes to complete a story? If yes, then why are they not in terms of time? Are they measures

> First of all, what are story points? Are they measures of time it takes to complete a story? If yes, then why are they not in terms of time? Are they measures of complexity? Story points are a measure of "relative amounts of effort". A 2 point story is twice as hard, as far as effort to implement it than a 1 point one. > Scrum meetings (aka rituals) have been among the most miserable hours of my life... Would you rather have many meetings almost every day, or a single big ol' meeting every few weeks so you can focus on coding without interruptions? > The review meeting causes utterly unnecessary anxiety (Oh my god, will my feature work?) It should not cause anxiety because it MUST work. The review meeting is to show stakeholders a "potentially shippable product increment". Everything you show on the review meeting should have been extensively tested already. > Why estimate stories that you are going to break down anyway? You only break down stories if they are too big. You are not supposed to work every detail on a planning meeting. > but in Scrum, the retro is explicitly supposed to be about the Scrum process itself, not about the codebase The retro is not about the scrum process but about how it is working for the team. All these issues you have already complained about should be reserved for this meeting where the whole team can decide which adjustments to make. > The main goal of Scrum is to minimize risk and make sure the developers do not deviate from the plan. I will come back to "Scrum controlmania" later. It is regretful that, like all the other "why scrum sucks" posts I've seen on HN, it all boils down to a bad scrummaster not managing expectations and taking the time to explain where the process really comes from.

JoeAltmaier 10y ago
For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part. When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up with some number. The planning phase is now over, so they're supposed to just execute, regardless of what (bogus) number they found. So they start. At the end of the sprint, they've done less than if they'd just started the task the first day. They get 'measured' as a low performer. Of course its the process that's performing badly, not the Engineer. They get frustrated, resentful and stop cooperating with the scrum master. I've seen this so many times at so many places its just exhausting. No amount of discussion can convince the evangelical Scrum experts that something is wrong with the process.
- vpeters25 10y ago
  In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell. Here is a quick 4 step planning meeting process based on planning poker: 1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it. 2. Team members pick an estimate of the effort. 3. If there is consensus, note estimate on story, pick next, goto 1. 4. If there is no consensus on estimate, have highest and lowest explain why they picked their estimate, goto 2. If you are expending more than 5 minutes on a story and there is no estimate, push it down and move on. It's not ready for development. The whole planning meeting should not take more than 1 hr. This process, allows everybody involved in development to have an idea of the overall project and chip in with their experience to impact estimates (this might require refactoring class X, it might be hard to test, will conflict with Y and Z, etc)
  - JoeAltmaier 10y ago
    And that's where the 'incremental tasks with no architecture' part comes in. When the scheduler needs rewritten to support whatever robustness; when the server feeds need to be redundant; maybe only 1 team member has any real idea what it takes. Coding isn't always about putting up another web widget or making another database entry.
    - vpeters25 10y ago
      That's the point: while there might be just 1 team member with a clear understanding of the effort, everybody gets to pick an estimate based on their own knowledge of the subject matter, even if they know nothing. The exercise of just enumerating in a couple minutes all the steps to complete such a story gives everybody, including the one who is going to do the job a clear idea of the effort or whether they need more information before proceeding. Btw, while Scrum is great for software development, they are not ideal for maintenance and/or infrastructure management where a defined process such as waterfall might work better. Trouble tickets and bug fixes should be kept outside the sprint unless they become stories.

JoeAltmaier 10y ago

For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part. When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up with some number. The planning phase is now over, so they're supposed to just execute, regardless of what (bogus) number they found. So they start. At the end of the sprint, they've done less than if they'd just started the task the first day. They get 'measured' as a low performer. Of course its the process that's performing badly, not the Engineer. They get frustrated, resentful and stop cooperating with the scrum master. I've seen this so many times at so many places its just exhausting. No amount of discussion can convince the evangelical Scrum experts that something is wrong with the process.

vpeters25 10y ago
In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell. Here is a quick 4 step planning meeting process based on planning poker: 1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it. 2. Team members pick an estimate of the effort. 3. If there is consensus, note estimate on story, pick next, goto 1. 4. If there is no consensus on estimate, have highest and lowest explain why they picked their estimate, goto 2. If you are expending more than 5 minutes on a story and there is no estimate, push it down and move on. It's not ready for development. The whole planning meeting should not take more than 1 hr. This process, allows everybody involved in development to have an idea of the overall project and chip in with their experience to impact estimates (this might require refactoring class X, it might be hard to test, will conflict with Y and Z, etc)
- JoeAltmaier 10y ago
  And that's where the 'incremental tasks with no architecture' part comes in. When the scheduler needs rewritten to support whatever robustness; when the server feeds need to be redundant; maybe only 1 team member has any real idea what it takes. Coding isn't always about putting up another web widget or making another database entry.
  - vpeters25 10y ago
    That's the point: while there might be just 1 team member with a clear understanding of the effort, everybody gets to pick an estimate based on their own knowledge of the subject matter, even if they know nothing. The exercise of just enumerating in a couple minutes all the steps to complete such a story gives everybody, including the one who is going to do the job a clear idea of the effort or whether they need more information before proceeding. Btw, while Scrum is great for software development, they are not ideal for maintenance and/or infrastructure management where a defined process such as waterfall might work better. Trouble tickets and bug fixes should be kept outside the sprint unless they become stories.