SlideShare a Scribd company logo

Project Management: Burn-Down Chart / OrangeHRM Project MOD (eng)

•
•
Anatoliy Okhotnikov
Anatoliy Okhotnikov

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

Related slideshows

New trends in testing automation
New trends in testing automationNew trends in testing automation
New trends in testing automation
 
Model-Based Testing: Theory and Practice. Keynote @ MoTiP (ISSRE) 2012.
Model-Based Testing: Theory and Practice. Keynote @ MoTiP (ISSRE) 2012.Model-Based Testing: Theory and Practice. Keynote @ MoTiP (ISSRE) 2012.
Model-Based Testing: Theory and Practice. Keynote @ MoTiP (ISSRE) 2012.
 
Continuous Integration In Php
Continuous Integration In PhpContinuous Integration In Php
Continuous Integration In Php
 
1 of 11
Download to read offline
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_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/

More Related Content

Project Management: Burn-Down Chart / OrangeHRM Project MOD (eng)

  • 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/