Tracker’s mission in life is to give teams an up-to-date snapshot of where they are and where they are headed. When we look at our project(s) in Tracker, we know for sure what we’ve done and what’s currently in progress. Tracker uses that information to help us visualize what we’re likely to be able to do for the next few weeks.
This applies to a physical task board on the wall, too. No matter what tools you use to track your software development, predicting the future is really just guessing. It’s good to help the business make plans. But beware the potential damage that can grow out of estimating stories, and planning based on velocity.
The most important benefit of an “estimating meeting” is the conversation that ensues about each story. Once we understand the purpose of the story and think about the simplest way to accomplish it, we can agree on its size. But if team members begin to debate whether a story is three, five or eight points, it’s time to stop and slice that story up into smaller, more easily estimateable sizes. And if there’s back-and-forth over one point versus two, pick a number and move on. Long discussions preceding consensus on estimates may mean you should go back to discussing the feature set at a higher level.
Estimating gets easier with experience. And the team gets more experienced at knowing the amount of effort each story will take. Mike Cohn reminds us that our stakeholders care about how much time the work will take, not how complex or hard it was for us to do. Breaking that work into more predictable chunks helps us provide that information. Smaller stories make the true scope more visible.
I worked at one company that had many development teams, each working on their own projects. I had a sinking feeling my first day on the job when I was taken on a tour, and told the velocity of each team. “Team Z are real rock stars; they have a velocity of 77!” That’s wrong on so many levels. Story points are relative, the scale is unique to the team, and quantity does not equal quality. That was just one of many symptoms of a troubled company culture.
Velocity is a planning tool, not a goal or a competition. Quality is a much healthier and more useful goal. You can learn to do a better job of slicing stories into small, consistent sizes. If you focus on quality, and master good practices in order to deliver business value frequently at a sustainable pace, your velocity will become a meaningful number that helps the business plan. But if you focus on speed, you’ll just grow a boat anchor of technical debt.
OK, so how do we avoid these perils and pitfalls? Some Agile pioneers now advise against estimating stories in points. I recommend reading these posts by Joshua Kerievsky and Ron Jeffries. Some practitioners, such as Woody Zuill, find it beneficial to not estimate at all.
And the old Scrum practice of “committing” to a certain number of stories or hours’ worth of work for the upcoming iteration was abandoned in favor of the concept of “forecast” a couple of years ago by the Scrum Alliance. My own previous Scrum team booted the commitment idea early on. It didn’t help us deliver faster or better. If you have the right people on your team and let them do their best work, you don’t need to add any “stretch goals.” If you don’t have the right people, commitment isn’t going to help. But the word “commitment” is like Mom and apple pie—it seems intrinsically good, and people think it will help the business trust the software team more. So, some companies seem to cling to the concept.
Remember, our business folks want to know when we’ll be done. Rather than try to predict this on an iteration-by-iteration basis with commitment, we can set visible milestones, with estimated delivery dates. We can evaluate our progress towards those milestones every day, and adjust delivery dates or scope as appropriate. Our business customers don’t like hearing that a release has been delayed, but they’d rather know that weeks ahead of time instead of the day before.
In my 13+ years working on agile teams, I’ve found it useful to “size” stories. Most importantly, I’ve found it useful for the team to learn how to slice features down into small, similar-sized stories. As I mentioned before, this makes for more predictable results.
I first learned about velocity working on my first Extreme Programming team. The XP folks explained it as “yesterday’s weather.” Today’s weather is likely to be the same as yesterday’s. So, you can’t sign up for more work in an iteration than you did in a previous iteration. If it turns out you get more done than the previous iteration, you’ve raised the velocity bar for the next one. If you average out the velocity for more than one previous iteration, you may get an even better idea for future planning.
When your team gets good at building up features with small, consistently sized stories, your team gets better at delivering about the same amount of work each iteration. With lower volatility, your team’s velocity becomes a more useful planning tool. The iterations planned into your Tracker backlog reflect past reality, and are useful predictions. Release markers keep delivery targets visible, and as grounded in reality as possible.
The number of story points your team gets done during the current iteration is less important than the date a particular feature may get delivered. Focus on doing things right to minimize technical debt, and building the right thing for your customers. Don’t worry about maximizing the number of story points.
Deliver early and often, so that you can provide small increments of value while getting quick feedback. Lean development has popularized the idea of minimum marketable features (MMF). Adjust scope for each MMF, set realistic milestones, and work to achieve a steady velocity.
Tracker helps make your past, current, and future work—including release milestones—visible. When you achieve a consistent velocity, your business can do useful planning. Unforeseen changes become obvious right away, so you can adjust accordingly. Over time, your team will achieve a dependable rhythm that drives the company forward.
Category: Productivity
