Scrum Developer Workflow
Hi. We are trying to put in place a process for our team to follow after not having a well defined one for a long time. Before, they just do "Scrum-but" in that they have Sprints. But usually, these are just arbitrary cutoffs. Sometimes they run for a very long time.
We don't have a Scrum Master yet. I am supposed to take that on. But have not undergone training yet. My knowledge is mostly from reading resources about Scrum online.
Anyway, I am proposing to follow the usual Scrum rituals. But one of our leads proposed the following workflow instead:
1. Assign/Self-assign tasks
2. Communicate to lead/senior the understanding of the tasks
3. Reviewed by lead/senior
4. Estimate Tasks
5. Sprint Planning
6. Start Development
His reasoning is that he feels that this has an advantage because if you assign and have the dev analyse it beforehand, they can then give a more accurate estimate. Also, that we can know how much we can commit in the sprint since it has already been estimated.
What issues do you see if we go with this? I know this will not be Scrum anymore.
It sounds like 2, 3, and 4 are what close to what is called Backlog Refinement in the Scrum Guide. The Scrum Guide recommends allocating about 10% of each Sprint's capacity to refinement activities - these could be individually, as a team, or some other combination. The purpose of this event is to make sure that the items in the Product Backlog are clear and defined enough to be planned and then developed by the Development Team in Sprint Planning.
1, 2 and 3 sound like they are against the spirit of self-organizing, cross-functional teams. It sounds like there is a desire to continue working individually, rather than as a team, and it also sounds like the team in general are not trusted to work without formalized guidance of a lead.
Such structures can stifle creativity, and limit a team's ability or willingness to reorganize itself when necessary, not to mention that it runs the risks of leads being bottlenecks in the entire flow.
How are Sprint Goals formulated and agreed in this workflow, given that tasks appear to be prescribed in advance of Sprint Planning?
"SIGH"
1, 2 and 3 sound like they are against the spirit of self-organizing, cross-functional teams. It sounds like there is a desire to continue working individually, rather than as a team, and it also sounds like the team in general are not trusted to work without formalized guidance of a lead.
Such structures can stifle creativity, and limit a team's ability or willingness to reorganize itself when necessary, not to mention that it runs the risks of leads being bottlenecks in the entire flow.
This is what I thought as well. But they insist that there are some things in the system that can only be implemented in a certain way. I think this can be fixed by having well defined guides for the devs to use as reference.
It sounds like 2, 3, and 4 are what close to what is called Backlog Refinement in the Scrum Guide. The Scrum Guide recommends allocating about 10% of each Sprint's capacity to refinement activities - these could be individually, as a team, or some other combination. The purpose of this event is to make sure that the items in the Product Backlog are clear and defined enough to be planned and then developed by the Development Team in Sprint Planning.
I have read about the refinement meeting. But do stories really get story points then? What's left to do in the Sprint Planning?
I think this can be fixed by having well defined guides for the devs to use as reference.
Could this be something that the organization should consider when it comes to crafting a definition of "Done"?
I think we definitely should consider this. Because I agree with your comment that the leads can become bottlenecks in this workflow. Not only that, but doing this will also take up their time.
How are Sprint Goals formulated and agreed in this workflow, given that tasks appear to be prescribed in advance of Sprint Planning?
We have not started with this yet. It's just that they are pushing it.
This person has communicated that he does not see the benefit of estimating the tasks during Sprint planning. Since if you assign and estimate beforehand, you can get a more accurate estimate from the assigned person. I don't believe I have better arguments than "Let us follow Scrum how it is prescribed first", and "A lot of teams have success doing this. Why can't it work for us".
If no Sprint Goals are being agreed with the Product Owner, then what is the point of sprinting? Is the PO satisfied with this situation and that good value is being delivered?
What issues do you see if we go with this? I know this will not be Scrum anymore.
Like Simon, I can see a lack of team-work, induicing a low focus (everyone has his own tasks) and a poor commitment (as spotted by Ian, no explicit goals but just going forward), low respect of the Developper (poor empowerment because of the "leads").
Scrum will help growing a true team.