Another Alternative Burndown Chart

Reality… average velocity changes throughout a project.  For any number of reasons—level of work, its difficulty, spikes, staff changes, holidays, etc.  No two sprints are the same in terms of content so it’s not reasonable to expect velocity to stay the same from one sprint to another.  Therefore, it can’t be the only variable to use to predict your final sprint.

Backlog changes too.  This is normal.  It just makes project tracking difficult unless you have a tool like NextWave ScrumMaster™.

Reading Mick Cohn’s article, Alternative Release Burndown Chart, reminded us why we designed the interactive ScrumMaster™ Burndown graph to project and handle backlog, velocity, and end dates the way we did.

As Mike points out,

“For example, suppose a team had expected to make progress of 40 hours, points (or whatever) last sprint, but the burndown chart only shows net progress of 10. Was the team slower than expected, or was more work added to the release?
It’s important to know the answer to this question, because we cannot really predict when the release will be done without it.”

Absolutely, and Mike shows you how to handle it using Excel.

Or, you can let ScrumMaster do the work for you and then some.  As you can see in the video, ScrumMaster automatically projects your ending sprint.  It also shows you when, where, and how your backlog grew.

If you are using ScrumMaster, here’s how it differs from Mike’s Alternative Burndown Chart.

  • Projections to finish date are simpler… and ScrumMaster does it all.
  • Want to see the trend line to project finish?  Choose the Average velocity menu option and you get the classic projection.
  • Backlog is automatically adjusted at each Retrospective (purple dotted line).  You don’t have to add anything.
  • All task work is color-coded, Original work plus any new work (Added tasks, Issues found, Software bug, Spike, Technical debt, Meetings).  There’s a ScrumMaster Report that tracks and analyses Backlog by type, by sprint.
  • You can select confidence levels for velocity and backlog estimates, to make automatic percentage adjustments to the projected ending sprint.  The greatest impact is usually seen early in the project cycle.
Estimating Agile Project End Dates

The interactive Burndown graph shows your project’s last sprint.

Make sense?  Give us a shout if you have any questions or comments.
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

NextWave ScrumMaster™: Estimating Ending Sprint for Agile Projects

Agile.  Scrum.  Project management.  When does this project finish?!!

As scrum masters and project managers, we live in the future as we constantly try to predict it.  If you’re already using ScrumMaster™, we sincerely hope it’s a tool that’s made your life easier.

If you’re new to ScrumMaster, this video shows you how to use NextWave ScrumMaster’s interactive Burndown graph to estimate when a project will finish.

NextWave ScrumMaster Video: Estimating Agile Project End Dates

How To video demo: Use interactive Burndown graph to estimate project end dates.

Closed captions (CC) can be turned on in the player.  The video transcript is here to download if you need it for translation.

Like it?  Let us know what you think!

Are backlog, sprints, stand ups and retrospectives part of your daily life?  Help build the community!  Follow us know so we know where we can follow you.  Send us a Tweet:  @NextWaveScrum
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

Updating Trial Version?


A few more tweaks to Reports and a couple of bug fixes.  Working #Lean and #Agile, we release versions as often as we can to respond to your user comments and needs.  Keep them coming!

Download the latest release from the Microsoft Store.  If you’re running any ScrumMaster version, you should automatically receive an update notice from the App Store (Windows 8.1 users may need to search for it).

Biggest enhancement to version 1.1?  A ScrumMaster demonstration project file to download.  Now you don’t have to build your own project in the trial version before you can see ScrumMaster in action.

Get more for ScrumMaster™
NEW:  Get more for ScrumMaster™, download DEMO project file from here
ScrumMaster Windows 8

Practice Safe Scrum!

Practice safe scrum… or be prepared to live with the consequences!

For some of us, too many ritual Agile meetings have not been a pleasant or productive experience, whether we’ve been running one or standing in one.  The reason is simple:  disrespectful human behaviour.  Late to start.  Off task.  Talking too much.  Not contributing.  Low level discussion of problems.  Attitude.  Egos running wild.  Finger-pointing.  Bad-mouthing of code—without even knowing who wrote it.  The list goes on.

There are many good ideas out there that get us closer to scrum ritual happiness, as in the example that follows.  (We pass along those we find as ‘Real Scrum Advice’ posts.)

Education has known for a long time it can give Business some pointers on proven techniques to modify and manage how any team functions—kids or adults.  Unfortunately, Business tends to think it knows all (or at least, Education knows a whole lot less).

Steve Peha’s interview with InfoQ was very interesting.  Not only did he talk about how Agile and scrum approaches can work in the classroom, but he also opens the door to insights for improving Agile adult work environments.  Because even in small teams where everyone basically gets along and works well together, implementing his key points reinforces positive team dynamics.

Why practice ‘safe scrum’?  Because the benefits of the ‘virtuous’ Agile cycle that results are tangible for the team, and they multiply.  Stress is reduced.  Confidence increases.  Collaborative problem solving improves results.  Productivity goes up.  People LIKE coming to work and they are HAPPIER.  The benefits extend all the way to the product end users, as the joy of work well done can transform the project.

“If we get past all of those fears to a place where we communicate more freely and more openly about what we do and don’t know, we can dramatically increase learning and remove the friction that often builds up when perhaps two people disagree and they let that disagreement just fester for day after day after day and sprint after sprint after sprint.”

Sound familiar?  How do you lead a team to improve working conditions, especially if the team doesn’t have a formal leader?  What if the team’s current cultural norms not only don’t support personal or professional ‘safety’, what if it functionally does the opposite?  Under the guise of ‘witty fun’ or other one-upsmanship power games, when barnyard politics rule, the resulting hierarchy doesn’t optimize team results.

Anyone can make a difference.  To begin, lead by example.  A well-timed candid observation to the group can be a catalyst for real discussion.  Team members talk one-on-one all the time, so there’s an opportunity to move gossip into something more productive… organize behind the scenes and then bring specific issues with suggested solutions it to the larger group.  Kick off a discussion of group norms.

Education folks might think in terms of:

#1  The Safety Message.  (verbally stated as a group norm and we all ‘walk the talk’)

  1. “Nobody will put you down or call you stupid.”  (to your face or behind your back)
  2. “There are no dumb questions.  Ask.”  (because somebody else probably has the same question and is reluctant to speak up)
  3. “Brainstorming Rules apply!”  (Have an idea?  Put it out there for discussion, NO JUDGEMENT on YOU, we just analyze the idea.)
  4. KEY:  As Scrum Master, you can say all this at the start of a new project and new team, but it needs to be modelled all the time and reinforced when necessary—by everybody.  Anyone making snarky comments gets called out immediately—by the group, not just by the scrum master.  Respectfully worded, as softly or directly as needed for that person to get the message.  Reinforces the positive for everyone.

#2  Positive team culture.  However you define it.  What is it now?  What would be better?  Is it…

  1. Professional?
  2. Inquisitive?
  3. Evolving?
  4. Customer centric?
  5. Caring?

#3  Structure.  For people and process.  Both need it for the team to function well.

  1. Vision is understood (the Big Picture, Team raison d’etre)
  2. Work is well organized (the bits and pieces, a solid WBS)
  3. Communication is planned (at least some)
  4. Progress is apparent (however measured and monitored)
  5. Success is celebrated (regularly, for real!)

Yes, it’s change management and it’s as complicated as the code you write.  And, it doesn’t happen over night.  Check out Mike Cohn’s comments about initiating Agile process in an organization as the challenges he notes can remain long after the introduction.

And when all is said and done, isn’t it really pretty simple?  It’s about RESPECT.  For other people and their code.

Of course, Scrum Masters using ScrumMaster™ can avoid holding team meetings for sprint planning, daily status updates, and end of sprint retrospectives altogether.  That’s one way to minimize uncomfortable team contact.  But, getting to the source of the issues and dissolving old patterns holds far greater rewards.
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

Common Agile Practices That Sabotage Us

Make Scrum dogma your own. Take what you need, leave what you don’t.  Here’s one more option to add to the article’s list.

ScrumMaster™ gives you the option in a Retrospective to take credit for work completed in the sprint. It automatically renames the remaining tasks and returns them to the Backlog… ready for evaluation at the next sprint planning session.

No, this isn’t orthodox Scrum procedure. But it makes sense, doesn’t it? It cleans up reports, too.
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

Mac of all Trades - Master of Some

Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress.  Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.


We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.

Impact to the Team:

  • Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
  • Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
  • Forecasting sprint plans and project schedules via velocity is useless here because the…

View original post 988 more words

Scrum Master: Position or Role?

To our way of thinking, Brian Lawrence nails it.  From the stony silence (and arrogance) he received when he broached the topic in an Agile group meeting to his concluding points.  However you implement Agile, it needs to fit well with your team structure and needs—and expect those needs to change over time.

Companies, organizations, projects, and teams are unique.  Size, project scope, and team talent varies.  One size—one dogmatic Agile approach—can’t fit all, even if it’s a good place to start. 

The definition and expectations of the Scrum Master role in a work environment shape the type of challenges faced when implementing an Agile approach. 

A team may find the natural progression of Agile in their company not only evolves the job of Scrum Master into a rotating role that anyone can do, for some teams, that role becomes that of a scribe:  the primary responsibilities are to run rituals (sprint planning, daily standups, and retrospective meetings), record changes in task status, and identify impediments and solutions that need to be escalated outside team. 

It helps if everyone is clear about the Scrum Master’s functional role within the team and relative to the rest of the organization.  Is the Scrum Master the Scrum dogma enforcer?  An Agile approach coach?  A mentor in Scrum methodology?  What flavour, strict ‘orthodox’ or ‘reformed’?  Couldn’t agree more, top down mandates don’t optimize teamwork or efficiency.  And when the project stalls, the “I followed every Scrum rule in the book” isn’t a valid management defense or excuse!  The only goal is to deliver superior product, on time, on budget.  And not make your team’s life miserable in the process.

Does the Scrum Master work with the product owner to establish priorities from a BUSINESS perspective, or is that handled by the Dev Lead that has a deep understanding of the individual project under discussion?  If you do rotate the Scrum Master role, you may need to separate out that function.

Having lived in these trenches, this is exactly why we built the NextWave ScrumMaster™ Agile project management tool.  Our work tools have to be flexible.  We need to be able to use them as it makes sense in our individual situations.


Scrum Master: Position or Role?            

Posted by Brian Lawrence
Nov 05, 2013

A couple months ago I attended a local Agile user’s group meeting and sat in on the Scrum Master Birds of a Feather session. I created a bit of a stir when I first asked, “How many of you have full time Scrum Masters?” All the other organizations represented turned out to have full time Scrum Masters. So, I then asked my second question, “What do they do?” I guess I had asked the question in a way that implied that full time Scrum Masters was strange, because I was greeted by several moments of complete silence. Most of the people, other than those from my own organization, looked at me like I had three heads. Finally, they indulged the obviously under-educated member of the group, namely me, with explanations directly from The Scrum Guide as to what a Scrum Master does. I shocked them further when I said that we had moved beyond the need to have full time Scrum Masters. I didn’t bother telling them that we actually never had full time Scrum Masters.

The Scrum Guide generally describes the Scrum Master role as one of teaching, coaching, facilitating, and removing impediments. And when a Scrum team is new, these things take time. A team new to Scrum tries to follow Scrum by the book and needs someone that can do a lot of teaching, coaching, facilitating and removing impediments. But what happens when the delivery team matures? Teaching lessens. Coaching lessens, though there is still need for coaching around constant improvement. Facilitating is still necessary, though this takes up very little time. And impediments lessen as the team learns to deal with them on their own. If one of the team members’ full time job is teaching, coaching, facilitating, and removing impediments and all these things have lessened to where that person is only needed ten to twenty-five percent of their time, what do they do the rest of their time?

For us, we took the following path. We started with Scrum, though I wouldn’t say strictly by the book. We came from a world where we had project managers running multiple projects, thus working with multiple project teams. Our first step was to train our project managers in Agile. Several of them took advanced courses. A couple even became certified Scrum Masters and Agile Project Managers from the Project Management Institute. Thus, our project managers (PM) became our first Scrum Masters. Due to resourcing constraints (we had more teams than PM’s) and possibly due to a little foresight, we did not immediately dedicate a Scrum Master to a single team. Yes, that’s right, we violated one of the Scrum rules right from the start. Each of our PM’s generally had two teams they worked with as the Scrum Master. This kept them busy, but did not overwhelm them. Their role, as you might guess, was to teach and coach the teams in Scrum, to facilitate the Scrum ceremonies, and to remove team identified impediments. And this worked for the first nine months to a year.

Fortunately for us, our Scrum teams matured. It became apparent to me that our set up with using PM’s for Scrum Masters was starting to become a problem when during employee one to ones I kept getting asked just what value the PMs (notice they were not referred to as Scrum Masters by the team) were adding to their team. The delivery team members felt like they were being over-managed by multiple people. They had their own functional managers and they had Scrum Masters who were not really part of the delivery team.

We made our first change in the structure. Each team was allowed to select their own Scrum Master from among the delivery team members. The Scrum Master would still be responsible as a full time delivery team member, but they would also facilitate the Scrum ceremonies and be the first point of contact for impediments to the team. What did we do with the PM’s? At first we left them as PM’s – doing some project management stuff such as cross-team coordination. But we also left them as Agile coaches. And coaching became something a delivery team asked for, not something that we imposed on them. This worked well. Those teams that were more mature in their Agile approach and understanding didn’t feel over-managed. Those teams still coming up to speed had someone they could go to for coaching.

One more minor transformation occurred as we continued to mature. We elevated the PM’s to program managers rather than project managers. They now became responsible for cross-team initiatives. These are projects that transcend products and have tasks / stories in multiple delivery teams. We also rearranged our management reporting where we went from functional managers / supervisors to delivery team managers / supervisors, a role we call the delivery manager. And it is the delivery manager that is now responsible for the Agile coaching and mentoring. We’re still working the kinks out of this model, but the teams are delivering well, so it seems to be working.

For us, Scrum Masters started as positions and evolved to roles as we became more Agile mature. We took the responsibilities of a Scrum Master and divided out the coaching / teaching parts from the facilitation / impediment removing parts. This works well for us allowing the teams to feel self-managed and allowing them to mature at a sustainable pace, as coaching has become something asked for rather than imposed upon them. It also allows more team members to experience the role, as many of the teams will rotate Scrum Master at set time periods. And we’ve found that any type of delivery team member can be a Scrum Master. We have business analysts, developers, and QA testers all being Scrum Masters. We’ve also found that even the coaching / teaching is staying within the delivery teams with the Scrum Masters, as the ones that gravitate to that role are the ones interesting in learning Agile principles and imparting that learning upon their teams.

Finally, the bottom line that makes management happy is that we have less people doing the same amount of work. We have sixteen delivery teams. Without the need for dedicated Scrum Masters, we’ve saved the need to have sixteen more people and with a fixed budget, that really breaks down to being able to have sixteen delivery teams, rather than only having thirteen teams because we’d need those extra people to fill a position that’s really a role.

My concern and the reason for this article, is really a warning to all of you out there beginning your Agile journey. If you hire a slew of full time Scrum Masters, which is happening at least here in St. Louis, you need to have a contingent plan as to what you’ll do with them as your delivery teams mature. And at least here, most of the Scrum Masters being hired are coming out of a project management background. Nothing wrong with that, but again, be prepared to answer the question, “Okay, now what do we do with all these PM type people that used to be Scrum Masters?”

About the Author

Brian Lawrence is currently an IT Director at TriZetto Provider Solutions in St. Louis, MO, where he is responsible for several Agile and Kanban product development teams, as well as application architecture. He has been a process junky since the days of Edward Yourdan. During his career he’s taken development organizations through several methodology transformations, including Rational Unified Process, Essential Unified Process, and Agile. He loves process improvement and looking at ways of developing software better, faster, and cheaper. His current passion is looking at ways to manage within an Agile environment.

Related Sponsor

 Agile Project Management That Adapts With You.
Provide your global development team a shared space that adapts to the  way they work.

ScrumMaster™ in Action

Here’s how ScrumMaster tools manage Agile projects.

ScrumMaster IS Agile

The tools and project management cycle. WiFi connects the Scrum Master to team members using Agile Story Sizing Cards™.
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone