Project Management: Burn-Down Chart / OrangeHRM Project MOD (eng)
Project Management: Burn-DownChart / 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 workleft to do vs. time. The outstanding work (or backlog)is often on the vertical axis, with time along thehorizontal. It is useful for predicting when all of thework will be completed. It is often used in agilesoftware development methodologies such asScrum. Burn-Down is the SCRUM artifact – a publiclydisplayed chart showing remaining work in the sprintbacklog. Updated every day, it gives a simple view ofthe sprint progress. It also provides quickvisualizations for reference.
What is Agile?Agile software development refers to a group of softwaredevelopment methodologies based on iterative development,where requirements and solutions evolve throughcollaboration between self-organizing cross-functionalteams.Agile methods generally promote a project managementprocess that encourages frequent inspection and adaptation,a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering bestpractices that allow for rapid delivery of high-qualitysoftware, and a business approach that aligns developmentwith 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 ManagementCustomers become a part of the development team (i.e. the customer must begenuinely 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" doesnot necessarily mean "producing more output."
Management ConcernsSprint progress - how is the team doing towardmeeting their Sprint goal?Release progress - will the release be on time with the quality and functionality desired?Product progress - how is the product filling outcompared to whats needed?*To answer these questions, you can assess ProductBacklog, Release Backlog (product backlog that hasbeen identified as required for the next release of theproduct), and Sprint Backlog contents and trends.
Burn-Down / Backlog Each backlog item contains the amount of work remaining. Thesevalues are updated continuously. Plot this backlog across time. Eventhough you might think that backlog should always go down, new work isalways being discovered as the product is being built. Expect the backlogto go up and down. Plot the slope of the backlog. If you draw a line representing averageslope over a period of time, you can project it to determine when no workis likely to be left (mission accomplished, Sprint goal reached, or releaseready for finalizing). Team velocity=actual work completed/days tocomplete. Manage empirically so that Sprint backlog and Release backlog reachzero when needed. You do this primarily by adjusting Sprint and Releasecontents or by modifying the Release date. This type of management produces "the best possible software". Theteam is doing what they can and you are helping them as much as youcan.
Team Signatures & Estimations Every team has different signatures. Backlog trends and velocityrepresent these team signatures. Youll learn these signatures and be ableto help teams adjust accordingly. For instance, some teams always haveSprint backlog that keeps going up during the first part of the Sprint, andthen descends dramatically. Assess the measurements and determinewhether this is because of inadequate Sprint planning, overwork duringthe last ten days (usually causes poor quality), or infrequent reporting ofwork remaining. Each team member is responsible for estimating the number of hoursremaining to complete all assigned tasks during a Sprint. As work iscompleted, new estimates (hours-effort remaining) are made until all workis completed.� These estimates are then summarized for all tasks andconverted to a burn-down chart which can be used to determine overallprogress being made during the Sprint.
Product Backlog / WorkRemaining 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. AsSprints build product, the Product Manager re-estimates (sometimes thefeature is only partially implemented) or zeros (feature completed) backlogitems. Work remaining reporting during a Sprint focuses on updates to theestimated number of hours to complete a task. This should not beconfused with time reporting. At the beginning of the Sprint, each teammember estimates the number of hours it will take to complete each of thetasks that they have been assigned for the Sprint period.� As the work iscompleted, a new estimate to complete is made for each task.� Thisprocess continues on a periodic basis until all tasks are finished duringthe Sprint.
OrangeHRM Project MOD Developed by SoftJourn to utilize Burn-DownPM 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 downthe work. Graphs: project, tasks, developers. – External interface for customers to view graphs. SHOW DEMO
References1. Burn-Down Charthttp://en.wikipedia.org/wiki/Burn_down_chart2. About Scrum – Work Burn-Downhttp://www.controlchaos.com/about/burndown.php3. Agile Software Developmenthttp://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/