The sprint (or monthly iteration) is the most visible aspect of the SCRUM process, in particular to developers, since all development effort takes place within the sprint.
The sprint starts with a sprint planning meeting at the beginning of the month where all stakeholders, including customers, product managers, marketing personnel, developers, testers, technical writers and others are present.
At this meeting, the engineering team presents a list of tasks from the product backlog that they believe they are in a position to complete in the sprint being planned. All other stakeholders participate in the presentation by giving their inputs. At the end of this meeting, everyone has a clear understanding of the work to be done in the sprint, and the end-deliverables.
Likewise, the sprint ends with a similar meeting at the end of the month, where the engineering team gives a demonstration of the features that have been added to the product during the just-concluded sprint.
Once the sprint planning is done, the engineering team becomes largely self-organizing, and is left alone to figure out how best to achieve their sprint goals. However, there are two important mechanisms to track progress and provide visibility for management during the course of the sprint. These are the daily stand up meetings, and the burndown charts.
The daily stand-up meetings.
The engineering team holds a very short internal meeting every day, known as the daily scrum. This meeting is also known as the daily stand-up meeting because it is suggested that all participants be standing through the meeting, as a mechanism to keep it focussed and brief. This meeting is called for and conducted by a designated leader, known as the scrummaster. The designated scrummaster typically is the technical lead, project manager or any of the developers in the team.
During this meeting, all participants are required to explain what they have accomplished in the past working day, and what they intend to complete in the upcoming day. They are also expected to raise any blocks they are facing (also known as “impediments”) which are preventing them, or has prevented them from meeting their goals. It is then the team lead's (scrum master's) responsibility to follow up on and resolve the impediments. The scrum master ensures that this meeting is focussed only on status updates and identification of impediments, and does not digress into an actual discussion of the impediments.
Once this meeting is over, all engineers go back to their desks to begin or continue work on their stated goals, while the scrum master works towards resolution of impediments.
The burndown chart.
Immediately after the sprint planning meeting at the beginning of the month, all teams do a detailed analysis of the tasks to be completed in the sprint, and prepare a list of subtasks they need to perform for every task. These subtasks would include all development activities, testing activities, documentation updates, etc.
Along with the subtasks, all team members also provide an estimate, specifically in hours, of the amount of time they expect to take to complete each subtask. It is recommended that the subtasks be as granular as possible, such that each subtask is between 4-8 hours.
Every day, all team members updates the estimate for the subtask they are currently working on, and replaces it with a value that represents the amount of time now left on it. This is important: at all stages, the estimates, whether original or updated, must represent as accurately as possible, the amount of time left to work on it.
A snapshot of this data (the estimates) is collected every day, and plotted on a graph with date on the X axis. Ideally, this graph should show a line going downwards from left to right, something like the one shown below (copyrighted image from www.scrumalliance.org):
As can be seen, this graph provides a very clear picture of the state of the sprint to all stakeholders. If the graph is moving horizontally, or upwards, it could be an early indication that all is not well, and that the team might not meet their sprint goals.
In my experience, a very effective usage of the burndown chart is for an automated system to generate them once a day, and and immediately email them to all parties.
The sprint starts with a sprint planning meeting at the beginning of the month where all stakeholders, including customers, product managers, marketing personnel, developers, testers, technical writers and others are present.
At this meeting, the engineering team presents a list of tasks from the product backlog that they believe they are in a position to complete in the sprint being planned. All other stakeholders participate in the presentation by giving their inputs. At the end of this meeting, everyone has a clear understanding of the work to be done in the sprint, and the end-deliverables.
Likewise, the sprint ends with a similar meeting at the end of the month, where the engineering team gives a demonstration of the features that have been added to the product during the just-concluded sprint.
Once the sprint planning is done, the engineering team becomes largely self-organizing, and is left alone to figure out how best to achieve their sprint goals. However, there are two important mechanisms to track progress and provide visibility for management during the course of the sprint. These are the daily stand up meetings, and the burndown charts.
The daily stand-up meetings.
The engineering team holds a very short internal meeting every day, known as the daily scrum. This meeting is also known as the daily stand-up meeting because it is suggested that all participants be standing through the meeting, as a mechanism to keep it focussed and brief. This meeting is called for and conducted by a designated leader, known as the scrummaster. The designated scrummaster typically is the technical lead, project manager or any of the developers in the team.
During this meeting, all participants are required to explain what they have accomplished in the past working day, and what they intend to complete in the upcoming day. They are also expected to raise any blocks they are facing (also known as “impediments”) which are preventing them, or has prevented them from meeting their goals. It is then the team lead's (scrum master's) responsibility to follow up on and resolve the impediments. The scrum master ensures that this meeting is focussed only on status updates and identification of impediments, and does not digress into an actual discussion of the impediments.
Once this meeting is over, all engineers go back to their desks to begin or continue work on their stated goals, while the scrum master works towards resolution of impediments.
The burndown chart.
Immediately after the sprint planning meeting at the beginning of the month, all teams do a detailed analysis of the tasks to be completed in the sprint, and prepare a list of subtasks they need to perform for every task. These subtasks would include all development activities, testing activities, documentation updates, etc.
Along with the subtasks, all team members also provide an estimate, specifically in hours, of the amount of time they expect to take to complete each subtask. It is recommended that the subtasks be as granular as possible, such that each subtask is between 4-8 hours.
Every day, all team members updates the estimate for the subtask they are currently working on, and replaces it with a value that represents the amount of time now left on it. This is important: at all stages, the estimates, whether original or updated, must represent as accurately as possible, the amount of time left to work on it.
A snapshot of this data (the estimates) is collected every day, and plotted on a graph with date on the X axis. Ideally, this graph should show a line going downwards from left to right, something like the one shown below (copyrighted image from www.scrumalliance.org):
As can be seen, this graph provides a very clear picture of the state of the sprint to all stakeholders. If the graph is moving horizontally, or upwards, it could be an early indication that all is not well, and that the team might not meet their sprint goals.
In my experience, a very effective usage of the burndown chart is for an automated system to generate them once a day, and and immediately email them to all parties.
No comments:
Post a Comment