Unfortunately Ive been at numerous companies on "agile projects" and have yet to see any of them tracking velocity-consistently-to even apply this. So imo, the real world challenge is that teams don't know how to properly decompose stories. As a result, they don't understand how complex a story is until they've pulled it into the sprint and started working on it. Imo, it takes a lot of OOA and OOD experience to decompose requirements in a sprint planning session and even then the meeting has to be driven by someone technical enough to visually represent the story on the board, then articulate all of the HIDDEN WORK required to realize it's completion. That level of maturity is difficult to find in companies today. Conversely, if a team is mature enough to know their real velocity, then they're likely mature enough to know what size story to bring in their sprint? Just my rough take. Cheers
Breaking down stories is hard. You're right though, over time teams will get better at it. The more mature a team is the better they are at sizing stories and knowing what can be completed in a sprint. I don't think teams need to be super mature to know their velocity though. You can figure out a velocity fairly quickly with good tracking. If a team constantly overcommits and can't complete everything in a sprint, try having them commit to drastically less (5 points if they normally commit to 15). Then gradually bring in more points. If they underestimate the size of stories, try breaking the story down into tasks. That should get the team thinking, and talking, about what actually needs to be done to complete the story. That extra step should help teams understand the size a bit more. Over time, teams will start to recognize the tasks quicker and gain a better understanding of the size of each story without needing to break it down as much.
I am the scrum master of a team of 6 devs, the velocity could be 70 or more. But if a 13 point ticket is planned into a sprint, is a red flag for us. Since for sure, if taken by only 1 developer, it will be finished near the end of the 2 weeks sprint, leaving too little time for UAT and fixing if necessary. This means 2 options: Or to try to split it in several independent stories to be done incrementally in different sprints or to do try to do it. If we do it, the secret of success is collaboration between at least 2 programmers or more. We would create tech sub tasks in jira for the story, back end and front end ones taken by 2 or more programmers at the same time. The story has to be taken right in the beginning of the sprint, and do daily code reviews and check points with other developers in the team, right after the stand up. In other words if no splitting is performed, the secret for finishing stories in the limit of size for the sprint, is encouraging good collaboration between developers.
Unfortunately Ive been at numerous companies on "agile projects" and have yet to see any of them tracking velocity-consistently-to even apply this. So imo, the real world challenge is that teams don't know how to properly decompose stories. As a result, they don't understand how complex a story is until they've pulled it into the sprint and started working on it. Imo, it takes a lot of OOA and OOD experience to decompose requirements in a sprint planning session and even then the meeting has to be driven by someone technical enough to visually represent the story on the board, then articulate all of the HIDDEN WORK required to realize it's completion. That level of maturity is difficult to find in companies today. Conversely, if a team is mature enough to know their real velocity, then they're likely mature enough to know what size story to bring in their sprint?
Just my rough take.
Cheers
Breaking down stories is hard. You're right though, over time teams will get better at it. The more mature a team is the better they are at sizing stories and knowing what can be completed in a sprint. I don't think teams need to be super mature to know their velocity though. You can figure out a velocity fairly quickly with good tracking. If a team constantly overcommits and can't complete everything in a sprint, try having them commit to drastically less (5 points if they normally commit to 15). Then gradually bring in more points.
If they underestimate the size of stories, try breaking the story down into tasks. That should get the team thinking, and talking, about what actually needs to be done to complete the story. That extra step should help teams understand the size a bit more. Over time, teams will start to recognize the tasks quicker and gain a better understanding of the size of each story without needing to break it down as much.
I am the scrum master of a team of 6 devs, the velocity could be 70 or more. But if a 13 point ticket is planned into a sprint, is a red flag for us. Since for sure, if taken by only 1 developer, it will be finished near the end of the 2 weeks sprint, leaving too little time for UAT and fixing if necessary. This means 2 options: Or to try to split it in several independent stories to be done incrementally in different sprints or to do try to do it.
If we do it, the secret of success is collaboration between at least 2 programmers or more. We would create tech sub tasks in jira for the story, back end and front end ones taken by 2 or more programmers at the same time. The story has to be taken right in the beginning of the sprint, and do daily code reviews and check points with other developers in the team, right after the stand up.
In other words if no splitting is performed, the secret for finishing stories in the limit of size for the sprint, is encouraging good collaboration between developers.
Biggest size is advisably 8 pts
I would try to avoid having one developer work solo on a story, especially one that big.
@@ireachagilityacademy If you're saying that because the team struggles to ever finish a 13, OK. If that is an absolute for all teams, no.