Calculate Story Points - Question from a course I dont understand
Hi guys,
is there anyone who can tell me why 250 / -15 is correct and how to calculate that?
"You are a Scrum Master and see the progress on a release burn down chart, which is shown as a bar chart. The following events are displayed: At the start of the project, there were 300 story points on the product backlog.
Sprint 1 was carried out by the development team with 25 story points.
In the sprint planning of the second sprint, a new story with 15 story points with a high value was created for the second sprint.
The development team closed this story with 10 points. It's called the 2nd sprint with 25 story points.
What does the bar chart of the Release Burn Down Chart look like now?
Consider an answer:
a. The upper edge of the bar is at 250 points, the lower at -15.
b. The top edge of the bar is at 50 points, the bottom at 0.
c. The top edge of the bar is at 260 points, the bottom at -10.
d. The top edge of the bar is at 40 points, the bottom at -10."
Why does it take multiple Sprints to effect a release?
Hi Ian. This was all mentioned in the training exam
What, exactly, is the source of this question? You may want to reassess the value of this training material since it doesn't seem to align with the Scrum Guide. I see several issues with the way the question is presented that make it very difficult for me to understand and answer.
Burndown (and burnup) charts are not a part of Scrum. Although teams may find them useful on a Sprint or release level of abstraction, how to create or use them are not defined in the Scrum Guide.
When a team chooses to use a burndown chart, I'm not sure why it would be depicted as a bar chart. I usually see burndown charts as line charts, where time is along the x-axis and scope (usually in Story Points) is along the y-axis. I'm not sure what a barchart would look like here, although I suppose it would just use bars instead of a continuous line.
It's not clear what is meant by "300 story points on the product backlog". It's often wasteful to spend time and effort estimating the whole Product Backlog. Usually, only a small portion of the Product Backlog has been sufficiently refined to be estimated by the Developers and considered ready for a Sprint Planning session.
I'm also not sure why a story with 15 Story Points was created at Sprint Planning. Creating a new unit of work at Sprint Planning seems like it leaves insufficient time for the team to understand and refine it sufficiently to start working on it. Unless it is extremely critical or time-sensitive, this doesn't seem like a good approach. Then, it sounds like the team reestimates, which is a practice that I'm not a proponent of.
Finally, I'm not sure why a bar chart for a burndown chart would ever be below 0. I don't know what that would indicate and that's not typical. A value below 0 would indicate negative work remaining. However, you suggest that this is the correct answer.
Most of my comments here also apply to your other question. You may have to consult someone with more expertise in your particular training, since the situation described just doesn't make sense to me. I would take a good look at the value in this particular training, though.
To answer the question, I suspect that Sprint 2 shows a bar that goes from +250 to -15, but the wording of the question is confusing and a bit fuzzy to me. -15 represents the points for the new story added, and gives a visual showing the Product Backlog grew. The points above zero respresent work remaining from the original estimates.
As Thomas states, typically burndown charts are represented with line graphs, but several years ago I did come across a team that was using a release burndown with bar charts. It is an alternate and valid approach, believe it or not, although rare and unorthodox. But for the team using it transparency was improved.
If I recall, the team wanted to show the impact of scope (measured in story points) being added to or removed from the Product Backlog. In other words, a bar that drops below zero shows story points added during a particular Sprint. A trend line would then show a forecast for how many Sprints a release might take.
I much prefer using a release burnup, which also shows the size of the Product Backlog over time.
In the world of complexity, there are no best practices, what works for one team may not work for another. Why not run an experiment with a release burndown bar graph and see what could be learned? But I am suprised this is taught.
That question is confusing and actually shows a poor understanding of Scrum. Here is how I understand the situation.
It states a Release burn down chart and 300 points in the Product Backlog. Then goes to mention activities in Sprint 2. So I'm assuming that this "Product Backlog" is representing a release and not a product and that the burn down chart is for the entire Product Backlog not a Sprint. Ok, sure you could do that but I'm not seeing how that aligns with the explanations of the Scrum Guide. It sounds much more like Project Management using some incremental, time box method.
A Scrum Product Backlog is not the same as a Release. In fact it would usually encompass many releases and even to the retirement of a product. Scrum is not designed for release or project management purposes, it is for complex work needed to create and maintain a product.
So, I'm not going to answer your question and choose to tell you to stop trying to answer those questions in a Scrum fashion. It is a project management assessment using Scrum terms inappropriately. If you really want to become better at Scrum, read the Scrum Guide (https://www.scrumguides.org/index.html) and use the assessments here.