Scrum projects make progress in short, timeboxed periods that other agile process call iterations. Knowing how to successful execute a sprint or iteration is vital to the success of any Scrum or agile development project.

Now vs. Not-Now Prioritization Along with Medium-Term Goals

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves,...

Schedule vs. Cost: The Tradeoff in Agile

To a large extent, agile is about making tradeoffs. Product owners learn they can trade scope for schedule: get more later or less sooner. Agile projects need to strike a balance between no upfront thinking and too much upfront thinking, a subject I’ve written about before.

I want to write now about a tradeoff that isn’t talked about a lot in agile circles. And this is the…

Know Exactly What Velocity Means to Your Scrum Team

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality...

Six Times Two Plus One Equals a Good Project Cadence

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month's newsletter I wrote about the idea that everything happens within a sprint. There is no "outside a sprint" during which team members might do things like design, bug fixing, or anything else. In this newsletter I want to share one possible exception to

When You Miss the Point of Sprint Planning Meetings

In a recent interview for an upcoming agile book by Sondra Ashmore and Kristin Runyan, they asked me questions regarding several areas of agile development and Scrum. In the last two posts, I explored questions about the product backlog and estimating. This time, I’d like...

Sprint Backlog Sums All Work Remaining

I want address a couple of common questions surrounding sprint burndown charts:

1) Is the burndown adjusted based on all tasks remaining in a sprint backlog or only those tasks that are in process?
2) During a sprint, if a bug is discovered on a user story being worked on, should we add additional tasks to the sprint backlog and should we adjust the burndown for those tasks?