Oh yes, and thank you for watching. Please support the channel and all the free content I provide. - Like, comment, and subscribe to the channel. - Why not join my community, free! Sign-up at onlinepmcourses.com/assets440251/the-onlinepmcourses-newsletter/ - And to show maximum appreciation, use the $ Thanks button, under the video, to make a small donation with a highlighted comment.
Great videos on theory, thank you, I learned a lot. Do you have a video on how to use it in practice? Have a few examples and how do you create the burn down or burn up chart from the beginning to the end from scratch on real life example?
Thanks for the video. What about this formula for Velocity? Total story points completed/number of sprints (rather than time elapsed) For ex: sprint 1: 30 SP, sprint 2: 25 SP, sprint 3: 35 SP So V= (30+25+35)/3 = 30 Story points per sprint Is this the average velocity? If yes, then, what will be the "time elapsed"? Like number of days, hours, minutes..?
Let's remember that, like so much else in project management, velocity is a metaphor. In physics (that's my background), velocity is strictly defined as the vector rate of change of position with respect to time. So, while you can of course calculate the rate of work per sprint, I would not call that a velocity measure (although, if sprints are all a fixed length, then it is clearly related by a simple parameter the sprint duration). So, others may call it a velocity, and they would be reasonable in doing so. Fr fixed sprint length, work per day is just work per sprint divided by sprint duration in days.
@@elhassaine Did you watch the video? The formula is on screen at 5:00. You can measure work completed in any unit (including story points) and time elapsed in any unit (including days, weeks, or sprints - as long as sprints are a fixed length). So, total story points completed/number of sprints is acceptable. By the way, the statement in para 3 of page 64 of PMI's Agile Practice guide implies that Velocity is 'the sum of the story point sizes for the features actually completed in this iteration' This is ONLY correct if the time unit is one iteration and you are only interested in a point velocity - that is, a velocity for a single iteration. I do not think this is a very helpful definition. It's sloppy and confusing.
Very well explained. Assuming I have a customer who wants me to budget how long a project will cost and also uses Earned Value calculations. How would I go about that in an agile environment?
If you think about it, a burnup chart is very much like an EV chart, where the units of value are the story points. The problem comes because of the mismatch between traditional PM's and Agile's approach to cost estimation. Many agilists eschew estimating costs, so EVM is anathema to true agile. But, for those of us who are committed to hybrid PM, we can allow ourselves to estimate cost and value for either one story point in general, or for each user story in particular.
Burndown Charts (and Burnup Charts) are a basic tool for many Agile teams. They help calculate Velocity - the rate of doing work. Let me explain...
Oh yes, and thank you for watching.
Please support the channel and all the free content I provide.
- Like, comment, and subscribe to the channel.
- Why not join my community, free! Sign-up at onlinepmcourses.com/assets440251/the-onlinepmcourses-newsletter/
- And to show maximum appreciation, use the $ Thanks button, under the video, to make a small donation with a highlighted comment.
Thank you! Finally found a video that really clearly explains these 3 concepts.
My pleasure - glad to have helped!
Best video about the 3 concepts
Thank you very much!
burndown: To show the remaining work in a sprint. burnup: : To show the total work completed over time
Indeed!
great. you are such an angel explaining novel pmp language clearly!
Thank you!
thanks... very useful
It's my pleasure. Thank you.
Great videos on theory, thank you, I learned a lot. Do you have a video on how to use it in practice? Have a few examples and how do you create the burn down or burn up chart from the beginning to the end from scratch on real life example?
Unfortunately not yet. I have a 'How to' video in my backlog.
Thanks for the video.
What about this formula for Velocity? Total story points completed/number of sprints (rather than time elapsed)
For ex: sprint 1: 30 SP, sprint 2: 25 SP, sprint 3: 35 SP
So V= (30+25+35)/3 = 30 Story points per sprint
Is this the average velocity? If yes, then, what will be the "time elapsed"? Like number of days, hours, minutes..?
Let's remember that, like so much else in project management, velocity is a metaphor. In physics (that's my background), velocity is strictly defined as the vector rate of change of position with respect to time. So, while you can of course calculate the rate of work per sprint, I would not call that a velocity measure (although, if sprints are all a fixed length, then it is clearly related by a simple parameter the sprint duration). So, others may call it a velocity, and they would be reasonable in doing so. Fr fixed sprint length, work per day is just work per sprint divided by sprint duration in days.
@@Onlinepmcourses Thanks, but I am trying to understand it based on PMI guidlines
@@elhassaine Did you watch the video? The formula is on screen at 5:00. You can measure work completed in any unit (including story points) and time elapsed in any unit (including days, weeks, or sprints - as long as sprints are a fixed length). So, total story points completed/number of sprints is acceptable.
By the way, the statement in para 3 of page 64 of PMI's Agile Practice guide implies that Velocity is 'the sum of the story point sizes for the features actually completed in this iteration' This is ONLY correct if the time unit is one iteration and you are only interested in a point velocity - that is, a velocity for a single iteration. I do not think this is a very helpful definition. It's sloppy and confusing.
Very well explained. Assuming I have a customer who wants me to budget how long a project will cost and also uses Earned Value calculations. How would I go about that in an agile environment?
If you think about it, a burnup chart is very much like an EV chart, where the units of value are the story points. The problem comes because of the mismatch between traditional PM's and Agile's approach to cost estimation. Many agilists eschew estimating costs, so EVM is anathema to true agile. But, for those of us who are committed to hybrid PM, we can allow ourselves to estimate cost and value for either one story point in general, or for each user story in particular.
👍
Thanks