Passed PSM-I with 90% !
Just Passed with 90%, throw me questions if you are on the way of pursuing the PSM-I :D
Do you get a question on burndown charts?
On a sample test I got this question: "Burndown charts provides information on velocity?"
False- is the correct answer
Do you agree/disagree with this answer?
Velocity is a method for accurately measuring the rate at which scrum development teams consistently deliver business value. Velocity is measured with the help of a velocity chart. A velocity chart shows the sum of estimates of the work delivered across all iterations.
A burn down chart shows how much work is remaining to be done in the project.
Product burndown is usually tracked in sprints (e.g. story points completed per sprint).
Sprint burndown is normally tracked in days (e.g. task hours completed per day).
Release burndown shows how quickly your team has delivered backlog items and track how much work the team must still perform to complete a product release. (e. g., story points, size, or hours per release)http://msdn.microsoft.com/en-us/library/ff731579.aspx
Why we can not measure velocity using burndown chart? This area is a little blurry to me? Any help clearing it out?
I basically agree but I don't think this a very good question. First, it does not say what kind of burndown it is (sprint/release) and how the burndown is calculated. Second, burndowns are not part of scrum so from scrum's perspective there is no right or wrong in creating the burndown.
Burndowns CAN show information about velocity depending on how and what you are tracking. The most typical sprint burndown shows remaining time for tasks in e.g. hours. This means that the while the sprint burndown can show steady progress you may end up with 0 completed items, e.g. 5 stories with 5 tasks each and 4/5 tasks completed for all stories would show 80% progress when in fact you have 0% progress. You are delivering stories (to meet the sprint goal) in the sprint, not tasks.
Fredrik is right, a velocity chart and burndown chart can show different information. A Sprint Burndown would normally show the burndown of tasks remaining...and story point velocity cannot be inferred from that.
A Product Burndown on the other hand would typically show work remaining on a Product Backlog, expressed in terms of story points or a similar measure. If that is the case then it *should* be possible to infer velocity from the data provided, but only if no waste (unplanned work) is incurred.
Suppose that a Development Team have to action an urgent requirement from the organization, and which did not come from the Product Backlog. A major incident such as an outage could be an example. The Development Team and the PO try to revise the sprint scope accordingly so as to accommodate it. The successful completion of this unplanned work could reasonably be held to count towards their velocity (since it is work done) but it would not contribute to the Product Burndown.
Which references you used to get such a score?