Scrumptious

by
Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog

RSS

Recent Posts

The Agile Engine

Scrum at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban

Scrum vs Kanban


We all love Scrum right? It provides a great framework for providing valuable solutions in an Agile way. When it comes to adopting an Agile framework within organizations, it really has no competitors. But often I get asked the question: "What about Kanban; is that a better way of doing things?"

Of course, this depends on how you define "better". If we are to understand these two powerhouses in the Agile world, it would be prudent to take a brief look at their similarities and differences:

 SCRUM

 KANBAN

Has specifically defined roles

Does not have mandatory roles

Uses Velocity, Burndown Charts to            manage and measure performance

Uses Lead Time, Cycle Time, WIP, Cumulative Flow Diagrams to manage and measure performance

Agile approach

Lean approach

Uses time boxes

No time boxes, just continuous flow

Work is based around capacity

Work is based around capacity

Daily meeting

Daily meeting

More structured framework

Less structured framework

Uses a product/issue backlog

Uses a product/issue backlog

More concerned with productivity

More concerned with efficiency

No changes allowed during Sprint

Changes can occur as needed

 
As Shakespeare might have said: "To Scrum or to Kanban, now that is the question." Actually, your organizational strategy or specific business requirement will answer that question better than Shakespeare could ever do. In reality, the two can exist together, and often do.
 
Take a software upgrade and rollout across an organization for example. Many projects such as this begin with Scrum (delivery of the solution), then transition to Kanban for support and issue logging (maintenance of the solution). This example might be closer to DevOps, but that is another buzzword for another buzztime!
 
Can you think of any other similarities or differences between Scrum and Kanban?
  


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

Posted on: April 30, 2019 11:49 PM | Permalink | Comments (29)

Burndown vs Burnup Chart

Burndown charts are a great visual way to track the remaining work on a Scrum project. You can track story points completed to get an indication of how your velocity is performing, or effort (in hours usually) to see how your expected completion date compares to your actual/probable one.

Burnup charts are used for a similar purpose, but they hold a key advantage over Burndown charts that not everyone new to Scrum/Agile is aware of. Personally, I love to use Burndown charts because my brain seems to be wired to see project work reduce over time, rather than see it start at zero and build up (with completed points) over time. Nevertheless, I have to concede that Burnup charts are a better tool and I will show you why.

Here's an example of a typical Burndown char:



You can see from the graph above that our project started with 100 story points, and that we expected (blue line) the project to be completed after 10 Sprints or iterations. Or in other words, around 10 points per Sprint. Our Velocity is therefore 10. The actual Velocity (red line) however tells a different story. We can see that is traveling slower than the expected target. In fact, the project completed after 12 Sprints.

Notice Sprint 7. The red line is almost flat. This can only mean that something happened during the Sprint to make the team slow down their Velocity. But what could it be? Did a team member go on holiday? Was someone sick? Did the Product Owner dump a bunch of work on the team which they accepted? Did the team come across a technology problem? Was the Scrum Master unable to remove an impediment to the team? Were there too many distractions from stakeholders? Was the estimation of stories not realistic? Perhaps the team just didn't fill in their completed stories yet?



This chart still tracks points and velocity, giving us the same information as the Burndown chart. However, notice the green line?  That is the scope (number of story points etc.) in our Scrum project. During Sprint 7, a further 10 story points were added to the project.

Remember that our Velocity was 10? Well, assuming that the team has done 10 points again during this Sprint (so on target with their Velocity), on a Burndown chart, this would have been displayed as a completely flat horizontal red line, even though the team did the same amount of work.

Both burndown and Burnup charts are great for the team to track their progress; burndowns more at the Sprint level, and burnups more at the Release level. However, Burnup charts are still great at the Sprint level.



We can see from the graph above that the team did very little for the first couple of days, and then picked up steam in the next few days to complete 38 story points worth of work. Notice the red scope line didn't change, but it could have, and we would have been able to see if very clearly. This information can be compared to existing Velocity and even placed on the Release burnup/burndown graph alongside points completed and other metrics.

So does all this mean throw away the Burndown chart and replace it with the Burnup chart? Well, not exactly. The Burndown chart has its place, and as long as you don't need to visually display if a slowdown in Velocity was due to an increase in scope, then a Burndown chart is fine. Yes there are Burndown charts that display histograms with bars that fall below the X axis. I personally can't stand these as I am old school; what is above the X axis and to the right of the Y axis stays there.

Given that OCD stipulation, the Burnup chart is in my view the best visual tool between the two.
 


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature
 

Posted on: April 16, 2018 09:49 AM | Permalink | Comments (24)
ADVERTISEMENTS

"I was gratified to be able to answer promptly, and I did. I said I didn't know."

- Mark Twain

ADVERTISEMENT

Sponsors