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:
- 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.
- 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:
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.