Does it make sense to have point thresholds for devs on a Scrum team?
My team works in 1 week sprints and a former PM set the expectation that everyone no matter if they are new to the team or senior should complete 30 points per sprint and that we can't have one person's sprint values set at a different threshold than the rest. Even if that person is new to the team and will take them longer to complete a task compared to a senior dev. What does Scrum say on thresholds? Personally, I don't think there should be thresholds but rather plan stories based on capacity per individual. Curious if anyone has run into something similar?
How is teamwork evidenced, with joint accountability for work undertaken and its outcomes?
Why are points a concern, rather than the delivery of value?
Why is a PM setting expectations at all?
The idea of people being told to achieve a set number of points per Sprint is wrong. The biggest problem is that it sets people up to focus on commitments to cranking out work, rather than a commitment to the goals and objectives of the team. It can also lead to gaming the point values of the work. I'd also be concerned about the individualistic focus, rather than a collaborative, cross-functional, self-organizing team.
Planning on individual capacity is also problematic for similar reasons. It focuses each individual on themselves and their own work rather than the goals of the team.
Estimates should only be used internally to the team in the context of checking the amount of work planned for the Sprint against the team's capacity. The estimates should be done by the team, considering the whole team, and the plan should be about the team doing the work.
what if the team say ok then it's 30 points to display a confirmation pop up ? Will it be any good for anybody ?
Totally agree with what everyone is saying. Like you all mentioned setting a number of points to complete per sprint causes for too much attention on achieving an arbitrary number and causes the team to be too focused on the points rather than the work.
We currently have everyone providing their own estimates, which wasn't the case in the past. I'm a firm believer in the person who's doing the work should set their own estimate.
@Thomas Owens, I'm referring to some sort of resource planning that would provide insight into allocation per team member. For example, if a team member is a lead on a project and is dedicating 20 hours per week on that project then we would know okay they have 10 hours to dedicate to something else. Instead of what we do currently, just assigning tasks without formal sprint planning. We have two senior backend devs who get the majority of the tasks because they know the systems.
Is there something else that you would recommend to help out product/project management plan better?
Why do you assign work at all? Why doesn't the team pull work on themselves as they have availability during the Sprint? In the end, the entire body of work is the responsibility of the entire team. Assigining work at the beginning of the Sprint is going to continue to encourage individual efforts.
I'm a firm believer in the person who's doing the work should set their own estimate.
Since estimates are supposed to be part of the Product Backlog Item, I assume you will have each developer assign estimates to tasks while the item is in the Product Backlog. Then during Sprint Planning each individual is trying to pull in exactly enough work for them to gain the target number. And if there is something in the Product Backlog that has recently risen in level of need but the people that provided the estimates are already over their 30 point mark it will not be pulled into the Sprint. This is going to be lead to all of the things that has been previously said and more.
Is there something else that you would recommend to help out product/project management plan better?
Resource planning is a project management tool/technique. Scrum and agile in general isn't about managing projects. It is more about adapting to change and delivering consistent value. Project Management doesn't really have a place in agile. Product Management is a crucial part but the actual implementation of Product Management changes in an agile environment.
I honestly believe that you are causing more problems by providing estimates than you are good. You have raised points to a level that is more important than deliverying value to the stakeholders. You should find a way to change the focus. How about if you used t-shirt sizing instead of story points. It would be really hard for someone to say that you need to complete 4 extra small, 3 mediums, and 1 extra large in every sprint. It would allow the team to focus on things like Sprint Goals which is intended to maximize the value that is being delivered each Sprint. It would allow focus on bodies of Product Backlog items that combine into potentially releasable increments of value being produced each Sprint. It would allow focus on teamwork instead of individual heroics.