Why you always fail the Sprint and three simple steps to fix the issues

In a typical project development that adopt the Scrum framework, you will do those activities required in the framework, such as doing the Sprint refinement, Sprint planning, run daily Scrum and then after 2 to 3 weeks doing the Sprint demo with the product increament, the Sprint is done following a retrospective, and you will iterate into next Sprint.

But is the Sprint really done and you will always get what has been planned in the Sprint planning? Most likely, the answer is NO, in fact there could be many times that your teams could NOT deliver the user stories that have been planned, which makes the Sprint failed to meet the goal.

There're multiple reasons why your Sprint would fail, in the post Re-think of Scrum-the Hidden sides?, I have presented couple of factors that are not in the landscape of Scrum, but if you do not consider those and take actions, most probably, you won't be able to deliver and because you could not deliver in the Sprint which would make your Sprint further unpredictable, you would get ever more worse performance, those form a negative feedback loop.

The most important reason of the "hidden sides" is the dependency, which includes both the user story/task dependency within a team and among several teams. Though one of the criterial of a good user story is the story should be independent, it would be very hard to meet this criterial in the reality, which means the dependency is inevitable at some time. It is relatively easy for a team to conquer the dependency issue if it only occurred within the team, but it would be tough if several teams have their tasks (and therefore user stories) depend on each other. If such dependencies happened without being managed, your Sprint would have a high possibility to be failed.

As you're aware that the dependency has high impact to the success of a Sprint, how should you manage it? here're the three steps help your to manage it effectively:

1.Plan your Sprint delivers according to your velocity

This is like what you've been doing in the Sprint planning activity, you will have to get all your teams together, pick up those user stories that should be developed in next Sprint based on their priorities and your average velocities measured from last three to four Sprints, and estimate the relative size. You confidence would be very high if all the estimated user story points add up has a small variance from the average velocity.

But do not think that your Sprint planning is done at this point, and your team should start to put their hands on the development immediately, your will need to do something more which are critical to your success.

2.Figure out those task dependencies among teams

Have all your team members write their tasks down on a big whiteboard, group those tasks with your individual team name, and start with one teams' task, ask two questions:

a. whether this task depend on any other taks

if the answer is yes, mark those tasks that this task depend on, move on to another task if the answer is no.

b. whether this task has other tasks that depend on it

mark all other tasks who depend on this specific task if the answer is yes, and move on to others if the answer is no.

Typically, you could start from the task that integrate all the deliverables from user stories to be delivered from each individual, and iterate this process with all user stories be covered.

This process won't take very long time as each of your individual teams' size is around 5 to 7 people and your Sprint is around 2 to 3 weeks.

Usually there will be a date on when the integrate task is expected to be started, and with that information, you should be able to put an estimated start date for all those tasks that depend on others and have dependencies.

3.Track those dependent tasks on your teams' whiteboard

At this step, your teams will know what're the tasks that they depend on each other, but you should try to revisit those dependent tasks at least two to three times to ensure that everythings has been covered, and the estimated date for each of those tasks are correct. At this time your teams should be very clearly on the big picture of the Sprint plan, and all those "critical" tasks in that plan.

Ask each team to paste their dependent tasks and their tasks that are dependent on their individual whiteboard, mark the critial information such as the team name and the expected start date on the task paster. Scrum masters from each team should ask questions on whether all the critical date on those tasks would be meet or not, if some of those tasks are risky then they should be high-lighted, and teams should get together to figure out action plan immediately.

Because the "critical" tasks would be checked in the daily standup, everybody from each individual team should understand what're the key deliverables that they need to make, so that the deliverables from other teams would be on time, which will further ensure the success of the Sprint.

Conclusion

A success Sprint planning is the key to the Sprint, both the Sprint velocigy and task dependencies are critical to a good Sprint planning. Your Sprint will be more predicatable and stable if you manage the dependencies and those "critical" tasks well.