Search this site
Burn Down chart and a change in scope that impacts the burn down chart
Filed Under Agile, Change, Features, Scope, Scrum | Posted on March 11, 2010
In the previous post (Burn Down Chart), we talked about what a Burn Down Chart is, and how you can use it to get the current status of the project, while not using it as a way of judging the performance of the team. This is because there are many variable that can impact the team, with one of them being changes in scope of the features that are included in the current Sprint cycle.
Typically, if you find that while viewing the burn-down chart that the amount of time available is not enough to do the required number of features / tasks pending, then there are multiple reasons that could cause this. One of the primary reasons is the changes in scope of features in the current Sprint. At the start of the Sprint cycle, when the Sprint Planning was happening, the team would have made estimates based on the user stories (and broken down tasks) defined at that time. Over the duration of the Sprint, there could be inaccuracies in estimates, but as you get a more experienced team, they get better at planning and estimating, and thus the amount of inaccuracies get reduced.
The other primary reason is changes in scope, but how do you show those on a burn-down chart, since the burn-down chart is one of the most used and primary means to determine status in Scrum. One way is to recalculate the chart based on the revised feature scope (although this would mean that the number of features you can do will reduce to account for this increase in scope). Keep an earlier version of the Burn Down chart handy since this helps in forming a sort of baseline.
Another way is to use the Burn Up Chart (refer this location) by Alistair Cockburn; where you can see progress and earned value. The burn-up project shows another line that depicts the total workload for the project, and this can be modified to show changes in scope. If there is no change in scope, then the line remains flat, but if there is an increase in scope, then it is pretty clear that there is an increase in scope, and hence, anybody viewing the graph can quickly make out the difference that the changes in scope have made to the entire project; consequently, the impact on the effort of the team and the amount of work that can be done in the remaining time.
Another thing that the ScrumMaster can do is to take a note of the changes in scope for the tasks as these changes become clear; Scrum is geared towards being as Agile as possible, but in the retrospective, it is always good to review these changes in scope to see which ones are coming because of changing requirements, and which ones are coming because of items that could have been clear earlier in the cycle (these need to be improved upon).
Burndown charts – a easy and powerful way to depict progress in the Scrum environment
Filed Under Agile, Scrum, Status | Posted on March 10, 2010
So what is a Burndown chart ? Seems a slightly weird name as compared to other documents whose names are more descriptive. Well, you will find that this name is also fairly descriptive. The burndown chart is a way to show the progress in a Sprint cycle, and differs radically from the milestone based progress tracking used in other methodologies. So what is a burn down chart ?
Well, a burn down chart tries to display progress in term of what’s remaining versus the time left in the Sprint cycle. At the start of the Sprint cycle, the team would have committed to a certain number of tasks in the current Sprint with the Story Points for each task defined (and thus you know the total amount of points available as well). As time progresses, the team would start completing the tasks, and the number of Story points remaining to be done would keep on decreasing. The amount of remaining Story points to be done by the end of the Sprint is captured in a Burn down chart. The advantage of doing the representation graphically is that it is very quick to make a deduction fro the graph as to whether the team is on track or not; and if the team can view them Burn Down chart on a regular basis, they will also be able to make the same calculation easily. The graph is a plot between the effort and time required, with the effort on the Y-axis, and the time on the X-axis.
In the Burn Down chart, there will be 2 plots, one showing the ideal decrease in Story points over the time period, with the reduction coming to 0 at the exact end point, and the other plot shows how the team is doing for the same time period. Minor variations can be fine, but if it becomes clear that the plot varies distinctly from the idea line, then some effort and planning needs to happen. Given that the Burn Down chart is updated at regular intervals, any deviation from the proposed number of features can be quickly caught and then action taken. However, one needs to be careful of the temptation to measure team performance linked to these charts, since there can be many factors that determines whether the team can meet the ideal curve (for example, if it were determined that the effort for a particular task was under-estimated because of any number of reasons; then the effort available for the total number of tasks will reduce).
Burn down charts provide an excellent way to portray the status of the team in terms of the number of tasks that they can do in the given Sprint, and the same can be used to depict the status on an almost day by day level (in our place, we calculate the burn down chart once every 2 days, and then show the graph at strategic locations around the office so that the current status is pretty clear to everyone).
A summarized checklist for use by a ScrumMaster running Scrum – how to be good at this role
Filed Under Agile, Scrum, ScrumMaster | Posted on March 9, 2010
Running a Scrum team is not very difficult, and a ScrumMaster can handle multiple Scrums (I have seen ScrumMasters handling multiple Scrum teams) as long as the timing of the daily Scrum meeting is modified. After all, you need to make sure that the team is there on time, are being brief and to the point, and you are ensuring that their impediments are being handled. Right, it’s that simple, right ? Well, there is a lot more you can do, to make sure that your Scrum team is working at peak productivity and efficiency, and this can be real rewarding for you to handle.
Here is an external checklist that is very detailed and useful (link to checklist).
The following is a much shorter version of some of the tips that seem to be useful in ensuring that you do a good job of the role of ScrumMaster. What are the things that you need to do or have (in terms of traits) that can help you be good at this role? Here are some tips:
- Be skillful in ensuring that you are not becoming the impediment for the team, or a bottleneck for the team. If you believe in the traditional command and control kind of system rather than the team being a empowered team, then you are doing a dis-service to the team or to the Scrum process.
- The ScrumMaster should work to ensure that the team treats the Daily Scrum as an occasion where the team talks to each other rather than to the ScrumMaster
- Work to anticipate problems rather than being reactive. If you only react to the impediments that are raised, then you will forever be chasing the impact of problems rather than working to prevent them from happening.
- Training. The ScrumMaster is a pivotal person who can provide guidance to the team about the processes followed in Scrum, work to ensure that they totally understand it, and point out issues as he sees it
- The ScrumMaster should never act as an intermediate between the product owner and the teams, even though the product owner may feel that their time is limited and would prefer the ScrumMaster to be the funnel through which information flow happens
- Work to get feedback and ensure that this feedback is incorporated. The team, especially after they get experience, typically has a lot of useful information to offer in the retrospective, but will continue to do so if they feel that their feedback is being valued and steps taken to incorporate the feedback.
- Once in a while, it is useful for the ScrumMaster to get some third party feedback, ideally by an expert in the process of Scrum
- Works to resolve dependencies. There are very few projects that are totally stand-alone, with teams being dependent on other groups (internal and external) in terms of either schedule of deliveries, or in terms of some critical technology. The ScrumMaster needs to take effective action to ensure that such dependencies are resolved in time.
- The ScrumMaster needs to have a checklist in place; this brings in a degree of thoroughness that can make the ScrumMaster even more effective (and also helps if somebody has to take over for periods in between)
- The ScrumMaster acts as a shield between the Scrum team and the external stakeholders such as management, engineering managers; this needs to be a very effective shield to ensure that people do not try to apply influence in a way that could affect the team.
Scrum terms – What is Velocity ? – a brief description
Filed Under Agile, Scrum | Posted on March 6, 2010
Scrum comes with its own set of terms, some of which should be familiar to all of you by now. This post will talk about the term called ‘Velocity’, which in normal English is a slightly scientific way of talking about speed. You would consider that Scrum will not deviate too much when using the word, and hence in Scrum-speak, Velocity refers to the amount of work that can be done in one Sprint cycle, and is partly derived from the experiences of previous Sprints. It is a summary of all the stories that the team done in the current Sprint, multiplied by the effort taken for each story, so if a team did 3 stories with an effort of 4 days each, and did 2 stories with an effort of 5 days each, then the Velocity for the team will be = 3*4 + 2*5 = 22. Note, for Scrum, we try to stay away from marking estimates with actual time intervals such as hours, days, etc, so when measuring the Velocity, the effort required for each story is defined in something called Story points rather than time durations.
So, when a Sprint cycle has completed (or multiple Sprint cycles have got completed), the team can review the amount of work that got done in these cycles, and develop a fair idea of what is the amount of effort that they can complete in the current cycle, and that actually becomes the Velocity. As you move over time and do multiple Sprints, the Velocity will be a very useful tool that will allow you to plan and predict the amount of work that the team can do in future Sprint cycles.
What does the ScrumMaster do about velocity, especially when the team is a bit new ? Well, if the team keeps on improving their Velocity as they move ahead on Sprint cycles, then that is a good movement, and the ScrumMaster can work with the team to understand the improvements that have happened, so that these can be built on. Conversely, when the team is not able to improve its Velocity or the Velocity even reduces, it is a bad sign for the team since it means that they are not able to generate the required level of accuracy, and even improve on these estimates. However, do not get into the concept of trying to compare the Velocity across multiple groups implementing Scrum; the effort that each group puts in, the amount of work that can happen, the degree of difficulty, all of these determine the actual amount of stories that the team can complete.
However, Velocity also means that you are looking forward, not looking at the amount of work that employees are actually doing; so if that means that an employee spent night and day resolving some complex issues, in terms of Velocity, it will be defined as a reduction of the amount of work required (and you might not even credit the employee for the amount of hard work required to get the work done as per time and schedule)
