(Professional Business Analyst Training

organisation)

BURN DOWN CHART

Burn Down Charts:-

A Burn down chart is probably commonly used chart in agile software development, where they are often used to understand and track the progress of the development of the project. 

This chart help’s you display the amount of remaining efforts for a given period of time.

 I think this is also a good project management tool which helps you understand when you are performing some particular task or iterating on a task, like, in how much time you have to complete it? and are you behind the schedule or are you a head of the schedule.

We can create a burn down chart in a spreadsheet program like excel and we do have a software tool such as “Intelligent Reports” 

which makes it easy to create a burn down chart for the project by using the data which is already contained in the project management system.

Let me take an example to show a simple burn down chart. 

So, here is the example we have eight tasks to be completed in Five days and each task is allocated some estimated working hours.

 As we see in terms of the remaining work, so we work as day 5 day 4 day 3 day 2 and day 1 respectively.

 So now see the below table and the graph.

Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.

   Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.

Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.

Often there is a wall between the BA/Business and the Development team.

Agile BA (Often called as Product Owner) is part of the team.

Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.

Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.

Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.