A new friend in Beijing sent us this. It’s always exciting to see your app in other languages—stoked we got featured in the Microsoft Store!
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.
Make sense? Give us a shout if you have any questions or comments.
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.
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
Poetically put. Essential to #Retrospective success.
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
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.
- New Windows 8 Application Release (nextwavescrummaster.com)
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’)
- “Nobody will put you down or call you stupid.” (to your face or behind your back)
- “There are no dumb questions. Ask.” (because somebody else probably has the same question and is reluctant to speak up)
- “Brainstorming Rules apply!” (Have an idea? Put it out there for discussion, NO JUDGEMENT on YOU, we just analyze the idea.)
- 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…
- Customer centric?
#3 Structure. For people and process. Both need it for the team to function well.
- Vision is understood (the Big Picture, Team raison d’etre)
- Work is well organized (the bits and pieces, a solid WBS)
- Communication is planned (at least some)
- Progress is apparent (however measured and monitored)
- 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.
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.
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