A Practical Approach to prevent sprints from becoming mini-waterfalls

Let me admit. Preventing sprints from becoming mini-waterfalls is hard.nature-waterfall

There are interesting articles out there (here & here) which explain how agile sprints are different from waterfalls.

The thing is to break big requirements into small byte sized user stories and deliver a few stories in every sprint. But the essential 4 step sequence does not change –1)  Requirement Analysis -> 2) Design -> 3)Code -> 4) Test

Teams start doing these 4 steps for each story within a sprint.

Update: This is fine as long as you don’t have any new type of requirements, for which the steps 1 & 2 are significantly time taking. Or the estimates are going to be hugely different based on the design. Meaning situations where lets say a new architectural block needs to be brought it, or a major arch/ design change needs to happen.

If you do have to bring in a major change in steps 1 and 2, then there are 2 problems here:

  1. Since the requirement has not been analyzed very well and the technical design is not done yet,  the estimates for these stories are going to be highly in-accurate.
  2. Second problem is that you would want to do related stories together with the intention of solving one ( or maybe two)  user problems in a given sprint.  If these stories are related then step1 and step2 cant really be parallelized for these related stories.

As a result the team would be doing step1 and 2 for the related stories in the initial phase of the sprint. Then the team would get to coding and then testing.  Producing almost waterfall ? Also, there is going to be very little certainty on the estimates & high chances of missing the sprint goals.

The Approach to mitigate the above problems:  Do the requirement analysis and the high level design before your main sprint starts. Meaning, take up these steps as a part of the previous sprint plan.

Here is how it looks:

 

Sprinting nicely

The orange boxes are the key.

Some part of the analysis( in the orange boxes) can happen as a part of the sprint pre-planning exercise and some can happen as dedicated stories for the team to work on.

Obviously, this wouldn’t be possible for when you have completely new stories coming in the next sprint which were not planned in advance but try to avoid that situation from a Product Planning/Scheduling standpoint. Also, stick to 2 or 3 weekly sprints.  The above approach would be very hard to do in-case 4 weekly or longer sprints.

This is what worked for me, would love to hear your thoughts and experiences in the comments section below.

Advertisements

2 thoughts on “A Practical Approach to prevent sprints from becoming mini-waterfalls

  1. I do agree with your points provided product owner has already prioritized the product backlog for atleast next 2 sprints. Onus goes to Product owner who is a front face to business and technical development team and he has to make the effective collaboration between Dev team and business so as to avoid any conflicts.

    1. Yup! And the way I look at it, onus is the engg team as well to push the Product Owner to plan at least 2 sprints at any point of time 🙂 so that the team can bring predictability in deliveries.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s