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

1. 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

2. 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.

3. 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.

4. 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.

5. 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."

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. References
1. Burn-Down Chart
http://en.wikipedia.org/wiki/Burn_down_chart
2. About Scrum – Work Burn-Down
http://www.controlchaos.com/about/burndown.php
3. Agile Software Development
http://en.wikipedia.org/wiki/Agile_software_development
4. Scrum (Development)
http://en.wikipedia.org/wiki/Scrum_(development)
5. OrangeHRM Project MOD (gForge)
http://gforge.sjua/gf/project/orangehrm/