How to start the sprint? What User Story is the right one to start to work on?
The successful result of a sprint depends on many different factors. It depends on how correctly the team has estimated, how good the commitment has been created. Whether there are any impediments, and if any, are there fixed quickly enough? Are the Product owners available during the sprint to answer any questions the team may have..?
Sometimes, even if all the issues mentioned above are not there, the sprint fails. It fails even when there are free team members.
I came across a situation when the team was under-committed, but still failed to deliver the sprint successfully due to the fact that the work/tasks were wrongly distributed.
A little insight about the problem
The team had in their commitment one user story that required 2 persons to work on it during an almost entire sprint. Only the specific 2 people could do the tasks. However, they had to start working on a different story first, then later to move to the big user story, resulting in shorter time left for the user story, hence resulting in a failure.
The real problem
The real problem occurs when there is a conflict between the User Story of highest priority and a User Story that needs to be started ASAP, due to time pressure, to be able to finish it until the sprint.
The standard practice is to start the sprint working on the US with highest priority and then move on to the 2nd, 3rd, etc. However in the situations described above, when there are User Stories that have lesser priority, are required to start as early as possible, confusion arises in the sprint.
Many agile advocates argue that it’s the Scrum Master’s job to find and elicit these kind of issues, however the scrum master is not always able to do that, the problem can be difficult to find.
The real causes
The real causes of the problems are that when the team sits down and discusses the initial commitment and breaks the User Stories down to tasks, they sometimes do not pay attention to the full picture of the sprint. The team members concentrate on separate user stories, and do not take into account the time dependencies, knowledge required for each use story and the availability of this and that person.
What to do? A proposed solution
The gut feeling plays a great deal in the sprint, estimations and commitment. Many times the Product Owners, Scrum Master or other people question the commitment, however it’s the team’s feeling of comfort with the commitment that needs to be most important, given that the team has a high competence and feels responsible for the success of the sprint.
The solution is, as soon as the team sits down to discuss the potential commitment, the team needs to look at the big picture:
- check which team members are required for which user story and whether there may be potentially conflicting cases
- check whether there are user stories that are critical to start early, even sooner that the top priority user stories
- in case stories like that exist, discuss that with the product owner, and communicate the risks. explain to scrum master clearly the case, to prevent future miscommunication
In one sentence, have an implicit Sprint Roadmap understood by the whole team.