Obviously, there are two problems with this setup. The team is too big and people are not dedicated to this project.
The chosen sprint size is 3 weeks.
The team attends the planning meeting. Maintenance issues are assigned weekly. The developers only know about their next two weeks load. They don't know their third week load. Everybody picks up stories considering their other commitments. The team ends up picking work worth only 150 hours for three weeks! Going by 6 hours per day per developer (if they were dedicated), they should have taken up at least 1014 hours worth of work!
The trained developer and the scrum master then walks up to the team's manager and requests him to do the following:
- The team should have dedicated developers as much as possible. People should be freed up from their other tasks if possible or else, people should be aware that they can delay / refuse to accept fixing any maintenance issues if they have picked up more work from the sprint.
- The team size should be reduced
The trained developer and Scrum Master keep pursuing this issue with the team's manager. They tell him that without having dedicated developers the team will never gain momentum and if they don't know about their other commitments at the time of planning meeting, they are likely to take little work because of unknowns. The Scrum Master also shows him his training manual that specifies the ideal scrum team size to be 5 to 7 members. Finally the manager agrees with this and promises to correct it in the next sprint.
No comments:
Post a Comment