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.

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone
Advertisements

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

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

The Vulnerable and The Invulnerable


Poetically put.  Essential to #Retrospective success.

Diary of a ScrumMaster

The Vulnerable considered options
The Invulnerable made a plan

The Vulnerable experimented
The Invulnerable stuck to the plan

The Vulnerable were open
The Invulnerable were defensive

The Vulnerable collaborated
The Invulnerable segmented

The Vulnerable listened
The Invulnerable assumed

The Vulnerable learnt
The Invulnerable blamed

The Vulnerable grew
The Invulnerable feared

View original post

Agile Problem Analysis


The Wheel of Life, the ancient Tibetan Dharmacakra symbol, represents dharma, the Buddha‘s teaching of the path to enlightenment.

Tibetan Dharmacakra Symbol

Dharmacakra: Tibetan Wheel of Life

Here is the NextWave Retrospective wheel we’ve created as a discussion tool.  We use it during #Retrospectives for sprint post-mortem discussions.

NextWave Retrospective Tool for Agile Analysis

NextWave Retrospective Tool for Agile Problem Analysis

As a mirrored variation of dharmachakra, it appeals to us and evokes the iterative cycle of waves… and the #Agile cycle.

We’ve found it to be useful to help us structure our thinking about any problem we’re analyzing.

Question #1:  We’ve defined a problem.
What’s its real source?

People?  (You?  Me?  Us?)

Process?  (How, who, when, what, where, why…?)

Or Product (Our understanding of the requirements?  The code itself?  Our approach?)

Once we’ve identified potential source(s), we ask: ‘Is the root of the problem at its source a Knowledge, Skills, or Attitude issue?’

Reflection and discussion often yield interesting insights.

Triangle of Success

Cool.  So now we think we understand the sources of the problem (there’s usually more than one).

Question #2:  What can I/we do about it?

Back to the NextWave Retrospective wheel.  Where, when and how can I/we impact change involving PeopleProcessProduct?  What will it take to bring about the change?  Who’s involved?  How?  Who’s taking responsibility to follow up with action?

And so the cycles and discussions continue…

Updating Trial Version?


RELEASE 1.1.1

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

Re-blog: Agile and Torque?


Cross-fertilization of ideas and inter-disciplinary analogies!

POWER (the rate of doing WORK) is dependent on TORQUE and RPM (the MEASURED quantities of engine output).

In Agile environments, does a similar relationship exist between Velocity and the team’s ‘torque’, the sum of each individual team member’s effort?

The extension of the ‘Knowledge-Skills-Attitude’ trilogy for success into a concept of project ‘work torque’ is a very interesting idea, introduced in Vinko Novak’s blog reposted below.

Triangle of Success

Think about it for a moment.  You’re always looking for ways to improve your team’s performance, or perhaps you’re facing a more specific issue, e.g., your team is struggling to use patterns effectively.  Why?

No finger pointing here!  As a management and basic problem solving tool rigorously applied, considering if a KSA area is the source of a team’s challenges could be a good first step that helps focus where potential improvements can yield the best ROI — whatever the desired outcome is or how it is measured.

Next, deeper analysis and reflection.  For the patterns example, is it really Knowledge or Skills that an individual or the team is lacking?  If so, those can be handled with relative ease, in a number of ways.  Is it Attitude?  If so, determine who, why, and the real sources of discontent.  Specifically tailor PEOPLE solutions to address those root causes.

However, perhaps the challenge isn’t about improving team KSA at all.  Could the source of the problem be as ‘simple’ as ineffectual communication about the patterns’ philosophy or use?  Or, the actual patterns themselves in this particular solution?  And what role does process play?

The variables are always many and complex, but the first step to finding a real solution is to deal with reality, as best as it can be determined.  The standard advice:  Make sure the right questions have been asked.  Make sure any responses address root cause.  And know that facing the possible answers sometimes takes courage!

REBLOG

See more from Vinko Novak at http://threelionheads.wordpress.com/.

Increasing Velocity by increasing the Team-Member Torque

SCRUM seems to be much about velocity and acceleration. So let’s stick to car terminology for a moment. If it is all about velocity and acceleration than contribution of each team member must be something like torque. Here is an interesting learn model I found very useful to define the actual torque. It’s called KSA (Knowledge, Skills and Attitude) model.

ksa

Knowledge is practically all a person knows and includes theoretical and practical learning. Everything you learn from experience is also knowledge. While applying the knowledge to the work, while practicing, you acquire or strengthen your skills. Skills are about how well you do things. For example programming skills, presentations skills and communications skills are common to software engineering. Attitude, from my point of view, is about how willing you are to do your work.

A scale factor for each layer of the model multiplied together gives the torque of the individual team member.

Lets define a scale, say 0 to 10, where 0 means not existing and 10 is maximum achievable value.

#example Having 7 in knowledge and in skills means 10 years or more of experience in certain field while continuously improving and learning ever since. But with a 3 in attitude you are probably dealing with the typical team member in “Waterfall”- organisations. The calculated torque for such a team member is  7x7x3=147. Out of 1000.

If SCRUM succeeds to change the attitude of the team members by more engagement, free decision making, clear focus, responsibility, commitment etc. the torque of each team member can rise dramatically (e.g. if we change the attitude in the example from 3 to 7 we get 7x7x7=343). This doubling in the torque might be a reason for the rise of velocity in SCRUM projects.

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.

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone