4 ms·

> Also don't assign time to points, that's completely missing the point. Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an imp

by bvrmn 6y ago

> Also don't assign time to points, that's completely missing the point. Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an implicit points -> time conversion table. And management can walk in and ask why you promise to complete a task in 1 point. It makes no sense at all.

yoz-y 6y ago
One article I quite liked was the one about Commoditized Excellence. https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/ https://barryhawkins.com/blog/posts/the-myth-of-commoditized... It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out. In this case you shouldn't be promising management anything because the points only mean something in the context of a team.
- bvrmn 6y ago
  If you dig deeper then scrum overall is a very complex thing trying to solve non-root problems. It is very ironic that scrum is Commoditized Excellence on its own. Scrum in a nutshell: 1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals! 2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity! 3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size. 4) How do we estimate? Planning poker every sprint! 5) And let's add formal process to evaluate every sprint to be more serious! It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.
  - yoz-y 6y ago
    If you remove buzzwords though it makes more sense: 1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered. 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future. 3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done. 4) How do we estimate this: empirically by progressive approximation. 5) This is not actually necessary. Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project. I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue. If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.
    - bvrmn 6y ago
      > 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future. Backlog on every level is always non-empty. So sprint filling is not a problem. Planning step is not about visibility. You can have a near roadmap with any process. But scrum tries to promise that we put only particular amount of tasks to be able to finish it. Sorta, in my experience there were only few finished sprint cases in different jobs with different teams, with and without scrum master. And from this moment scrum goes over the rails. Why we need this restriction at first place?

by bvrmn 6y ago

yoz-y 6y ago

One article I quite liked was the one about Commoditized Excellence. https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/ https://barryhawkins.com/blog/posts/the-myth-of-commoditized... It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out. In this case you shouldn't be promising management anything because the points only mean something in the context of a team.

bvrmn 6y ago
If you dig deeper then scrum overall is a very complex thing trying to solve non-root problems. It is very ironic that scrum is Commoditized Excellence on its own. Scrum in a nutshell: 1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals! 2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity! 3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size. 4) How do we estimate? Planning poker every sprint! 5) And let's add formal process to evaluate every sprint to be more serious! It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.
- yoz-y 6y ago
  If you remove buzzwords though it makes more sense: 1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered. 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future. 3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done. 4) How do we estimate this: empirically by progressive approximation. 5) This is not actually necessary. Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project. I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue. If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.
  - bvrmn 6y ago
    > 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future. Backlog on every level is always non-empty. So sprint filling is not a problem. Planning step is not about visibility. You can have a near roadmap with any process. But scrum tries to promise that we put only particular amount of tasks to be able to finish it. Sorta, in my experience there were only few finished sprint cases in different jobs with different teams, with and without scrum master. And from this moment scrum goes over the rails. Why we need this restriction at first place?