7 Agile Software Development Part 3
R. Baskaran
Burn-downs charts are among the most common sprint tracking mechanisms used by Agile practitioners. Though their application and usage varies (some plot a burn-down chart using story points, whereas others use task count), plotting burn-down using effort remaining is the most effective and efficient way of using burn-down charts. This article looks at creating and updating a burn-down chart using the effort-remaining approach, interpreting burn-down under different scenarios, and examining common mistakes to avoid while using burn-downs. We conclude by looking at some of the benefits of using this innovative tool.
How to create a burn-down chart
The first step is to have a task breakdown in place. This is generally done during the sprint planning meeting. Each task should have associated hours (ideally not more than 12, roughly two days’ work at six per day), which the team decides on during the planning meeting.
Once the task breakdown is in place, the ideal burn-down chart is plotted. The ideal reflects progress assuming that all tasks will be completed within the sprint at a uniform rate (refer to the red line in Figure 1 below).
Many Agile tools (Rally, RTC, Version One, Mingle, etc.) have built-in capability for burn-down charts. However, in its simplest form, a burn-down chart can be maintained in a spreadsheet. Dates in the sprint are plotted on the X axis, while remaining efforts are plotted on the Y axis.
Refer to the example below:
Sprint Duration – 2 weeks
Team Size – 7
Hours/Day – 6
Total Capacity – 420 hours
On Day 1 of the sprint, once the task breakdown is in place, the ideal burn-down will be plotted as below:
Figure 1
The Y axis depicts total hours in the sprint (420 hours), which should be completed by the end of the sprint. Ideal progress is shown in the red line, which assumes all tasks will be completed by the end of sprint.
Updating the burn-down chart
Each member picks up tasks from the task breakdown and works on them. At the end of the day, they update effort remaining for the task, along with its status.
Refer to the example below; the total estimated effort for Task 1 is 10 hours. After spending an entire day (six hours) on the task, if the developer believes that it requires another six hours to complete, the “Effort Remaining” column should be updated as 6.
As we progress during the sprint, the burn-down will look like this:
Figure 2
Interpretingthe burn-down chart
The blue line in the figure above shows the remaining effort on a daily basis. If the blue line is above the red line, it means we are going at a slower pace and may not be able to complete all the commitments. If the blue line is below the red line, it shows that we are going at a better rate and may be able to finish earlier.
Type 1: Sprint commitment met (smooth flow)
The figure below provides a burn-down chart in which sprint commitments are met and progress has been smooth over the sprint.
Figure 3
Type 2: Sprint commitment NOT met
In the burn-down chart below, sprint commitments were not met. Work of around 100 hours was not completed in the sprint. The remaining work then become part of the product backlog and was carried forward to subsequent sprints.
Type 3: Team stretched toward end to meet the commitment
In this burn-down chart, the team worked at a slow pace in the first few weeks of the sprint and pushed toward the end of the sprint to meet the commitment.
Figure 5
Type 4: Team is not consistent
In the figure below, though the commitment is met in the end, the team’s performance has not been consistent. Probably it is a case of meeting weekly goals by stretching toward the end of every week.
Figure 6
Multiple stories have a common task.
There are instances when multiple stories may have a common task involved. In such scenarios, if we add this task under each story, it will provide a wrong impression of total hours, and tracking will be misleading. For example, consider “test data set-up.” This could be a generic task and applicable for all stories.
A better way to handle this would be to add just one task that is common across stories. This ensures that efforts are not increased multifold. Another way could be to divide total effort for tasks by number of stories and add tasks under each story, specifying divided effort hours. However, in such cases, while updating the task, team members should remember to update it under all stories.
Tasks are too detailed or too big.
If there are too many tasks created, it becomes difficult to track them. At the same time, tasks should not be huge in size (ideally not more than 12 hours), or else daily tracking will be difficult. Generally, if tasks are more than 12 hours, it becomes difficult for team members to assess how much effort is remaining at the end of the day, and tracking may become subjective.
There is misunderstanding between effort remaining and effort spent.
One of the most common mistakes we commit is it to misunderstand “effort remaining” as “effort spent.” Especially during first the few sprints or when a team is new, the team needs to be educated on this. While updating the effort column every day, the team should be reestimating the task again and update what effort is remaining to complete the task.
If the team updates “effort spent” rather than “effort remaining,” burn-down will initially show downward trending, and as the sprint progresses, the blue line will cross the red line and show an upward trend. It will look something like this:
Figure 7
Discipline is needed to update daily.
It requires a disciplined effort from everyone to update “effort remaining.” It should be done at the end of every day. This helps in coming up with a burn-down chart that reflects the correct picture daily.
Advantages ofusingburn-down charts
Single planning and tracking tool for the team
The team comes up with a tasks breakdown, the team updates estimated effort, and the team also updates effort remaining. This empowers the team to own the plan. The entire team drives planning and tracking using the burn-down tool, which is the biggest advantage of using it.
- Scope management: Tasks represent the overall scope of the sprint. Anything that is not part of the task list is out of scope for the sprint.
- Schedule management: The team plans what it has to accomplish in a sprint and updates the task list. As it updates daily effort details, the team knows whether it is on track to meet the commitment or not.
Risk mitigation by daily visibility
Schedule overrun and cost overrun are two important metrics that get tracked in traditional project management. Mostly they’re tracked on a weekly basis. The burn-down chart, on the other hand, provides daily feedback on effort and schedule, thereby mitigating the risks and raising alarms as soon as something goes wrong. For example, if actual progress line (the blue line) goes flat and hovers high above ideal line (the red line), the team knows it is in trouble. Mitigations can be planned right then, rather than waiting till the end.
Communication tool for customer and other stakeholders
Burn-down charts are an effective communication tool for customer and stakeholders. This can be printed and placed in an Agile room or shared with relevant stakeholders every day. This provides visibility of project progress on a daily basis. In the absence of an online tool, burn-down can be physically represented using a whiteboard/chart paper and placed in the team area.
Placeholder to track retrospective action items
It’s a good practice to include retrospective action items from the previous sprint as “nonfunctional requirements” in the task breakdown for the current sprint. This way, the team keeps a focus on those action items, and they are also tracked as the sprint progresses.
Dynamic Systems Development Method (DSDM) is a framework based originally around Rapid Application Development (RAD), supported by its continuous user involvement in an iterative development and incremental approach which is responsive to changing requirements, in order to develop a system that meets the business needs on time and on budget. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance.
DSDM was developed in the United Kingdom in the 1990s by a consortium of vendors and experts in the field of Information System (IS) development, the DSDM Consortium, combining their best- practice experiences. The DSDM Consortium is a non-profit and vendor independent organisation which owns and administers the framework. The first version was completed in January 1995 and published in February 1995. The current version in use at this point in time (April 2006) is Version 4.2: Framework for Business Centered Development released in May 2003.
DSDM Public Version 4.2 (www.dsdm.org) was made available for individuals to view and use in July 2006. However, anyone reselling DSDM must still be a member of the not-for-profit consortium.
As an extension of rapid application development, DSDM focuses on Information Systems projects that are characterized by tight schedules and budgets. DSDM addresses the common reasons for information systems project failure including exceeding budgets, missing deadlines, and lack of user involvement and top management commitment.
DSDM recognizes that projects are limited by time and resources, and plans accordingly to meet the business needs. In order to achieve these goals, DSDM encourages the use of RAD with the consequent danger that too many corners are cut. DSDM applies some principles, roles, and techniques.
In some circumstances, there are possibilities to integrate practices from other methodologies, such as the Select Perspective, Extreme Programming (XP), and PRINCE2, as complements to DSDM. Another agile method that has some similarity in process and concept to DSDM is Scrum.
Principles of DSDM
There are 9 underlying principles of DSDM consisting of four foundations and five starting-points for the structure of the method. These principles form the cornerstones of development using DSDM.
User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace, so that the decisions can be made accurately.
The project team must be empowered to make decisions that are important to the progress of the project, without waiting for higher-level approval.
DSDM focuses on frequent delivery of products, with assumption that to deliver something “good enough” earlier is always better than to deliver everything “perfectly” in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase.
The main criteria for acceptance of deliverable in DSDM is on delivering a system that addresses the current business needs. It is not so much directed at delivering a perfect system addressing all possible business needs, but focuses its efforts on critical functionality.
Development is iterative and incremental, driven by users’ feedback to converge on an effective business solution.
All changes during the development are reversible.
The high level scope and requirements should be base-lined before the project starts. Testing is carried out throughout the project life-cycle.
Communication and cooperation among all project stakeholders is required to be efficient and effective.
Prerequisites for using DSDM
In order for DSDM to be a success, a number of prerequisites need to be realized. First, there needs to be interactivity between the project team, future end users and higher management. This addresses well known failures of IS development projects due to lack of top management motivation and/or user involvement.
The second important prerequisite for DSDM projects is the decomposability of the project. The possibility of decomposition into smaller parts enables the iterative approach, and activities, that are hard to prioritize, often causes delays. And that is exactly the effect that DSDM was developed to avoid. Another group of projects for which DSDM is not well-suited are safety-critical ones. The extensive testing and validation found in these kinds of projects collide with DSDM goals of being on time and on budget. Finally, projects that aim at re-usable components might not be well-suited for development using DSDM, because the demands on perfection are too high and collide with the 80%/20% principle described earlier.
The Phases of DSDM
The DSDM framework consists of three sequential phases, namely the pre-project, project life-cycle and post-project phases. The project phase of DSDM is the most elaborate of the three phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step approach in developing an IS. The three phases and corresponding stages are explained extensively in the subsequent sections. For each stage/phase, the most important activities are addressed and the deliverables are mentioned.
Phase 1: The Pre-Project
In the pre-project phase candidate projects are identified, project funding is realized and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project.
Phase 2: The Project life-cycle
The process overview in the figure above shows the project life-cycle of this phase of DSDM. It depicts the 5 stages a project will have to go through to create an IS. The first two stages, the Feasibility Study and Business Study are sequential phases that complement to each other. After these phases have been concluded, the system is developed iteratively and incrementally in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The iterative and incremental nature of DSDM will be addressed further in a later section.
Feasibility Study
Business Study
Functional Model Iteration
Design and Build Iteration
Implementation
Phase 3: Post-project
The post-project phase ensures the system operating effectively and efficiently. This is realized by maintenance, enhancements and fixes according to DSDM principles. The maintenance can be viewed as continuing development based on the iterative and incremental nature of DSDM. Instead of finishing the project in one cycle usually the project can return to the previous phases or stages so that the previous step and the deliverable products can be refined.
Core Techniques of DSDM
Timeboxing
MoSCoW
Prototyping Testing
Workshop
Modelling
Configuration Management
Timeboxing
Traditional Project Management uses milestones where as DSDM uses timeboxing technique.Is an interval, usually no longer than 2,4 or 6 weeks, where a given set of tasks should be achieved.
Timebox
Can contain several tasks.
At the end need to deliver a product.
Are subject to change since tasks are defined ,not what to be delivered.
Can change the tasks during time box iteration which allows for rapid response to business needs.
DSDM drops functionality in flavor of delivering in time.
MoSCoW Rules
DSDM projects are concerned to be in time and on budget and users are heavily involved in the development process. So it is mandatory to keep on watch on what users need the most.
User requirements may change ( during the process) ;
Aware of new technical possibilities
User work environment changes
The DSDM techniques to weight the importance of requirements are the MosCow rules. And the rules are as follows,
1. Must have : All features classified in this group must be implemented and if they are not delivered, the system would simply not work
2. Should have : Features of this priority is important to the system but can be omitted if time constraints endanger.
3. Could have : These features enhance the system with functional items which can easily be reassigned to a later timebox.
4. Want to have : These features only serve a limited group of users and are of little value. Prototyping
Evolutionary prototyping in DSDM projects satisfy 2 principles,
Frequent Delivery
Incremental development
Implements critical functionality first so can discover difficulties early in the development process and allow having early deliverable to get user feedback.
The necessary feedback-loop is provided by a workshop which is the last important technique in a DSDM project.
DSDM differentiates on the following for types of prototypes,
- Business Prototype : Allow assessment of the evolving system
- Usability Prototype : Check the user interface
- Performance Prototype : Ensure solution will deliver performance or handle volume
- Capability Prototype : Evaluate possible options
Key Success Factors
The DSDM consortium has compiled 10 most important factors from its members:
- Acceptance of DSDM philosophy before starting work.
- The decision making powers of users and developers inside the development team.
- The commitment of senior user management to provide significant end-user involvement. Incremental delivery.
- Easy access by developers to end-users. The stability of the team.
- The development team skills.
- The size of the development team.
- A supportive commercial relationship. The development technology.
Weakness of DSDM:
- Licensing cost
- Relatively high barrier to entry
- Cultural shift in organization
At the core of DSDM are similar principles and practices to all other Agile methods i.e.:
- Breaking business requirements into small components – user stories
- Prioritising these components according to the business need
- Delivering, testing and accepting these components in small time windows
- Delivery through a collaborative team that includes the end users
- Regular and transparent feedback on both the solution and the process
DSDM adds a number of useful concepts and advantages to the Agile body of knowledge specifically:
- A framework, practices and guidance for getting an Agile project started and governed. Proper initiation and governance processes for change are critical for all large organisations and none of the other Agile methods recognise this
- Detailed definitions of the roles in an Agile project team which helps people new to Agile to transition effectively
- In particular, DSDM has 3 roles to represent the business which more accurately reflects how most organisations deliver change. This is more nuanced and practical than the Product Owner concept in Scrum
- More sophisticated prioritisation through the use of MoSCoW guarantees on-time delivery of the Minimum Usable Subset of functionality
- It embraces business change aspects of a project rather than just focusing on software development and can be used for projects that have no software
Where DSDM typically needs support from other Agile methods is in:
- The detail of software engineering where techniques such as continuous integration, automated testing and code coverage from XP fit smoothly
- The detail of testing each User Story and Feature (Epic)
Quadrant 4 – Learn More/ Web Resources / Supporting Materials
|
Web Links |
| http://www.tutorialspoint.com/software_engineering/software_engineering_overview.htm |
| http://www.practicalprocess.com/seyp/definition.html |
| http://www.softwareengineerinsider.com/articles/what-is-software- engineering.html#.V44IRtJ97Dc |
|
Supporting & Reference Materials |
| Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001. |
| PankajJalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997. |
| Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000. |
Glossary
| Starting char | Term | Definition | Re late d Te rm |
| S | Software Engineering | It is the building of software systems which are so large or so complex that they are built by a team or teams of engineers | Software Development |
| C | Change Control | Change control is a systematic approach to managing all changes made to a product or system | Versioning |
| R | Reliability | It is the probability of failure-free software operation for a specified period of time in a specified environment. | QoS, Software Quality |
| C | Cost Estimation | It is the approximation of the cost of a program, project, or operation. | Estimate |
Points to Ponder
| S.No | Points to Ponder |
| 1. | Good notations can clarify the relationships and interactions of interest. |
| 2. | The existence of standard practices is one of the distinguishing characteristics of a professional discipline. |
| 3. | Team communication, product complexity, facilities and resources, etc are some of the quality and productivity factors. |
| 4. | Functionality, reliability usability, efficiency, maintainability are some of the characteristics of software quality. |