Project Management: Burn-Down Chart / OrangeHRM Project MOD

● What is Burn-Down Chart?● What is Agile? Scrum?● Adaptive Project Management● Management Concerns ● Burn-Down / Backlogs● OrangeHRM Project MOD● References

What is Burn-Down Chart?

A burn down chart is graphical representation of work left to do vs. time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. Burn-Down is the SCRUM artifact – a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

What is Agile?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

What is Scrum?

● Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.

Adaptive Project Management

Customers become a part of the development team (i.e. the customer must be genuinely interested in the output.)Scrum has frequent intermediate deliveries with working functionality, like all

other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.

Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.

Transparency in planning and module development—let everyone know who is accountable for what and by when.

Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)

There should be an advance warning mechanism, i.e. visibility to potential slippage or deviation ahead of time.

No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.

Workplaces and working hours must be energized—"Working more hours" does not necessarily mean "producing more output."

Management Concerns

Sprint progress - how is the team doing toward meeting their Sprint goal?

Release progress - will the release be on time with the quality and functionality desired?

Product progress - how is the product filling out compared to what's needed?*To answer these questions, you can assess Product Backlog, Release Backlog (product backlog that has been identified as required for the next release of the product), and Sprint Backlog contents and trends.

Burn-Down / Backlog

Each backlog item contains the amount of work remaining. These values are updated continuously. Plot this backlog across time. Even though you might think that backlog should always go down, new work is always being discovered as the product is being built. Expect the backlog to go up and down.

Plot the slope of the backlog. If you draw a line representing average slope over a period of time, you can project it to determine when no work is likely to be left (mission accomplished, Sprint goal reached, or release ready for finalizing). Team velocity=actual work completed/days to complete.

Manage empirically so that Sprint backlog and Release backlog reach zero when needed. You do this primarily by adjusting Sprint and Release contents or by modifying the Release date.

This type of management produces "the best possible software". The team is doing what they can and you are helping them as much as you can.

Team Signatures & Estimations

Every team has different signatures. Backlog trends and velocity represent these team signatures. You'll learn these signatures and be able to help teams adjust accordingly. For instance, some teams always have Sprint backlog that keeps going up during the first part of the Sprint, and then descends dramatically. Assess the measurements and determine whether this is because of inadequate Sprint planning, overwork during the last ten days (usually causes poor quality), or infrequent reporting of work remaining.

Each team member is responsible for estimating the number of hours remaining to complete all assigned tasks during a Sprint. As work is completed, new estimates (hours-effort remaining) are made until all work is completed.� These estimates are then summarized for all tasks and converted to a burn-down chart which can be used to determine overall progress being made during the Sprint.

Product Backlog / Work Remaining is NOT Time Reporting

The Product Manager is responsible for maintaining Product Backlog, along with estimates for how much work is required for a backlog item. As Sprints build product, the Product Manager re-estimates (sometimes the feature is only partially implemented) or zero's (feature completed) backlog items.

Work remaining reporting during a Sprint focuses on updates to the estimated number of hours to complete a task. This should not be confused with time reporting. At the beginning of the Sprint, each team member estimates the number of hours it will take to complete each of the tasks that they have been assigned for the Sprint period.� As the work is completed, a new estimate to complete is made for each task.� This process continues on a periodic basis until all tasks are finished during the Sprint.

OrangeHRM Project MOD

Developed by SoftJourn to utilize Burn-Down PM methodology.

Features: – New “Project” tab with functionalities provided. – “Project Plans” for PMs, “Customers” for Admin, “Burn Downs” for Employees. – Create “Project Plans” backlogs and burn down the work. Graphs: project, tasks, developers. – External interface for customers to view graphs.

SHOW DEMO

References

1. Burn-Down Chart http://en.wikipedia.org/wiki/Burn_down_chart2. About Scrum – Work Burn-Down http://www.controlchaos.com/about/burndown.php3. Agile Software Development http://en.wikipedia.org/wiki/Agile_software_development4. Scrum (Development) http://en.wikipedia.org/wiki/Scrum_(development)5. OrangeHRM Project MOD (gForge) http://gforge.sjua/gf/project/orangehrm/