Burn down charts

GOZCUGOZCU Member Posts: 234
Hello guys,


I just wonder how many of you are using the "Burn down chart" for you project management or even as a motivating tool. ? What do u think about burn down and burn up charts ? Which one do u think fits to your goals better ?

Generally I use it for my certification studies. Number of pages or number of labs should be made in a specific time and burn down chart shows me if i am ahead of the project or coming from the back....

Tell me your opinions pls...

you may also share your templates, which will be appreciated :)

Comments

  • GOZCUGOZCU Member Posts: 234
    It looks most of us didn't know about it or didn't find it worth to use. I highly recommend to use it...

    here is a small pdf about it;

    http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf
  • N2ITN2IT Inactive Imported Users Posts: 7,483 ■■■■■■■■■■
    Just printed out I am going to read it later. Thanks for sharing this resource
  • MAC_AddyMAC_Addy Member Posts: 1,740 ■■■■□□□□□□
    GOZCU wrote: »
    It looks most of us didn't know about it or didn't find it worth to use.
    Please wait more than a few hours to post a comment like this. The majority of posters on here are in the US and are on a completely different time to you.
    2017 Certification Goals:
    CCNP R/S
  • JDMurrayJDMurray Admin Posts: 13,093 Admin
    I've been in Agile software development projects were the PMs lived and died by the daily progress made--or not being made--on burn down charts. They seem mostly to be a way for the higher-up in management to judge how a project is proceeding, and not much use to the people who are actually getting their fingers dirty do the real work.

    There is a "best case" burn down projection that's impossible to maintain, a "projected" burn down based on perform in similar past projects, and then what you really get because of all the unexpected problems. Collecting metrics is a huge part of making burn down estimates and projections. If you don't know how to collect metrics from your project, or don't have any past metrics to work with, you won't know if your burn down projections are reasonable or not.

    After a while you get so tired of hearing in the daily scrums about how the team isn't meeting the burn down projections that you'll become resigned to a "I'll get done what I can get done" defensive attitude. The PM needs to back off of this daily bad news for the sake of the team's morale.
  • GOZCUGOZCU Member Posts: 234
    MAC_Addy wrote: »
    Please wait more than a few hours to post a comment like this. The majority of posters on here are in the US and are on a completely different time to you.

    that's right. I forgot about it ^ sorry
  • GOZCUGOZCU Member Posts: 234
    JDMurray wrote: »
    I've been in Agile software development projects were the PMs lived and died by the daily progress made--or not being made--on burn down charts. They seem mostly to be a way for the higher-up in management to judge how a project is proceeding, and not much use to the people who are actually getting their fingers dirty do the real work.........


    that's a good one. So in some cases these kind of charts may cause to some negative effects. Especially when it makes the team members stressful about somethign which is really not about their own daily job.


    But I think, it also matters how a project management comments on the chart. You can easily characterize the person from the chart, like " if he is dividing the projects to the small pieces and doing it with a schedule, or waiting up to the end, lying for whole time about the task and doing it at the last week" This doesnt mean PM should go and warn but better to know the personnell better."
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    The IT department at my company uses the Agile-Scrum project management methodology to manage both infrastructure and software development projects.

    We don't use burndowns, though, because we are a small team an we know what we are getting done from our daily scrums. If our projects were the ones making money, though, I am quite sure that Sr. management would be interested in seeing them. When we initially started with scrum we tried burndowns but it was just too much of a pain to keep them up for the benefit that we didn't really get from them. This was mostly because we were all filling multiple rolls and did not have dedicated PMs.
Sign In or Register to comment.