You develop software? This may help you organizing the team better.
“A goal without a plan is just a wish” …… Antoine de Saint-Exupery
Agile, It’s all about flexibility in the course of software development phase. But flexibility is not possible without a proper plan in place.
Even when we decide the architecture of a software, we often keep in mind that the software stays flexible to any changes in future and therefore design patterns come into picture.
Planning plays a vital role in the software development life cycle. It not only gives a better idea for the upcoming sprint but for the entire project delivery timelines. This is the reason why agile helps each and every stakeholder involved in the process.
Before moving ahead to the stuff, we would like to portrait a bigger picture of what is actually a iteration and how it is involved as a part of the bigger agile process.
Let us understand it with an example,
Suppose you are preparing for a half marathon 3 months down the line. The date is fixed, the target is fixed and obviously your effort as well.
What next ?
Well you need a #PLAN in place to get ready with the weapons to hit the bulls-eye.
You need stamina to run the marathon, strong muscles to avoid muscle fatigue, good shoes (if new, get comfortable with them) and many more.
So you start visualizing the end result and hence prepare a road-map to achieve the desirable step by step. And this step by step road-map is actually a bundle of iterations where each step is called one iteration in agile software world.
Similarly in software development,
Deadline is fixed, features/product is fixed and you need some step by step plan to achieve it. And hence we come up with the step by step road-map to analyze the development pace and the assurance of the delivery and hence the iteration.
As we go with the book,
Iteration planning is a collaborative effort involving these roles: Scrum Master: Facilitates the meeting. Product Owner: Represents the detail of the product backlog items and their acceptance criteria. Delivery team: Define the tasks and effort necessary to fulfill the commitment.
Iteration planning should start way before the start of the iteration. Let me guide you through step by step
Step 1 : (Backlog* grooming)
For Iteration X, The grooming of the features (stories*) should be done in this iteration in iteration X-1. The product owner and some team members take some time out of their capacities and plan for the next iteration in advance.
*Backlog is nothing but a list of stories in our pipeline for near iterations to come.
- A user story is a small feature that follows invest.
- Know more about user stories and story points
After the story grooming, the stories are shared with the whole scrum team for their better understanding and to help them prepare for the viewpoint they will put across in pre-iteration meetings.
The best thing about backlog grooming is that you have enriched product backlog for the times to come and you have ample number of time to decide the priorities for the same.
Backlog basics :
A product backlog that should follow DEEP principle i.e
Detailed appropriately, Emergent, Estimated, and Prioritized
Typical steps in backlog grooming :
- Analyse the customer, user and quality assurance team’s feedback
- Integrate the learning and come up with improvements or features
- Decide what to do next on the basis of their priorities
- Write detailed user stories around the features/improvements, decide when to pick them up and enrich the product backlog.
Typical backlog Image could be like this (Image source learnpub.com)
Step 2: (Pre-Iteration meeting)
At about the end of Iteration X-1, One should commit 1–2 hours of the whole scrum team to discuss the plan for the upcoming iteration. All team members come prepared with their level of understanding on the stories as shared with them in Step 1.
Here we discuss the user stories one after another and let everyone share their viewpoints. We discuss why we are doing such a story from the product owner to understand the product growth and customers feedback.
Sometimes some unexpected scenarios come into picture after these valuable discussions (and that is when reason we should not mind extending these to more than 2 hours at times). At this stage, we should decide the tasks to complete the story and fill it there and then on our Agile board for future reference.
Moreover we discuss all possible stories that we are going to pick up in the next iteration as suggested by the product owner. With all stories well understood to the team, we go ahead to the next step of planning where we plan for what, why and how the stories must be performed.
Step 3: (Iteration meeting)
Iteration meeting is a one hour opportunity for each stakeholder to come across with their viewpoints and decide what all we are going to do in the coming iteration. Iteration can last anywhere between 1 week to 1 month.
A typical iteration planning looks like the image as below.
Story commitment :
On the basis of the tasks involved and the complexity of the stories decided in the pre-iteration meetings, Estimate the relative size of the story and the individual effort of each team involved in the same. Basis which you should plan the handful number of stories to be done in the iteration as per the priority shared by the product owner.
For each story discussed, it is the team who finally decides whether they commit the story in the iteration or not. Sometimes due to higher story complexity, dependency on some external factors, some understanding issues or no bandwidth left for other sub-team, one should not commit the story in such scenarios.
Committing a story means the team takes the complete responsibility of completing the same.
Let me clear the above line with an example,
Before our iteration meeting, we all come prepared with our capacities for the upcoming iteration. We plan for leaves, training and other organizational level tasks well in advance and share the individual capacities. Know more about capacity planning
Depending upon the total team members, You will get the cumulative number of hours of each sub team. For example, say we have bandwidth of 250 hours from Dev team, 90 hours from Front End team and 120 hours from Quality assurance team. So we have to keep in mind the bandwidth of each team so that we can complete the story in the iteration.
We commit stories so that no team stays dangling in the iteration. In such case, we pick up sub-team independent stories. Like dev only story, unit tests, HTML only stories, optimization tasks from the pipelines, server optimization, internal purpose reporting tools etc.
Changes to the user stories:
“Stay committed to your decisions but stay flexible in your approach“ ……. Tom Robbins
Once the story is committed to the iteration, it should not be changed. Any Changes, modify the scope of the story and therefore the scope of iteration which is actually an ignorance of all the planning we did as of now. It also leads to the inconsistent burn down chart and may affect the deliveries of other committed stories as well.
An iteration is recommended to be of small period, because any changes to the user story can be catered in the next iteration as it is not that far. Often we do not get into such problems because what we plan in the iteration is planned well at least for the upcoming iteration.
Only in case of priority one issues (like some issues on production environment) we pick up those immediate issues and this is also prioritized by the product owner.
Step 4 (Iteration) :
After the stories are decided, we start the iteration where each sub-team pick up the stories as per the availability and capacities.
Plan for the order in which stories will be picked such that each and every resource is completely utilized and we can give maximum throughput.
Now what ?
Now the iteration starts and on the day 1 of the iteration. Decide the stories we are picking up first so that we can deliver them for the next sub-team waiting for the story.
For example, Dev waiting for Front end integration, Quality Assurance waiting for the story’s dev done, Front End waiting for Design team recommendation etc.
And hence the iteration planning for iteration X, remember a few hours of this iteration will be used to plan the iteration X+1.
This cycle continues.
Learning is a part of planning as well :
After the end of each iteration,
Retrospective meeting should be conducted to identify the learning, the pitfalls you faced and how you can improve in the next iteration.
These improvements from the iteration X are the part of planning of the iteration X + 1.
Burn Down Chart helps to identify the constant delivery by the team. As the story is completed it burns down on the chart thereby bringing the commitment graph lower. It should be a linear line approaching zero i.e full commitment delivered.
Velocity Report helps to identify how much the team has delivered in the iteration as per the commitment and what is the average story points the team is able to deliver in the given sprint.
Build Quality Report helps in keeping track of the build quality in each and every iteration. To know the quality of the build and the various factors impacting it.
These all reports lead to constant delivery, better quality and a better team.
Agile is to make stories live as soon as the story is verified. This is a beautiful process that helps the team to deliver constantly. Iteration over iteration team becomes responsible, brings more ownership and delivers quality product.
We go to the granular level possible and deliver them independent of other portions of the feature/product.
An iteration is the whole and sole of the agile. It is the smallest step possible to reach the milestone.
You must have heard that
“A long journey starts with a single step”
So we encourage you to take that single step and make history. We will keep writing such blogs to help you out or share our experiences with the rest of the world.
“I am writing it to help you out, you should recommend it to helps other out”
Hit the subscribe button for more such articles.
Keep smiling and keep growing.