How to use Iterations and track velocity in Shortcut

Recently we launched Iterations in Shortcut and we’ve been excited by the feedback we’ve received for this highly requested feature. This is a powerful feature and so, we want to share ways to get the most out of Iterations as well as how to avoid common pitfalls.

Keep Iterations short for better prioritization

Iterations are best used to plan, scope, and track Stories to be worked on, in a timeboxed period of time. We recommend keeping your Iterations as short as possible. Depending on your particular team, a month is already quite long. Ideally, an Iteration length of a week or two weeks is preferable. Shorter Iterations allow your team to be responsive to ever-changing customer needs and business strategy while being focused on the highest priorities in the current iteration.

Assign consistent Iteration lengths to allow for better data

Iterations are also used to track velocity (how many Stories or Story Points) your team has accomplished over time in previous Iterations. This aids in planning future iterations, since you can help business stakeholders understand how much work you can probably accomplish going forward, providing a bit more predictability to help plan for business goals more broadly. So you should have the same length Iterations over time, preferably non-overlapping, to provide that simple, consistent velocity data.

Use velocity to guide prioritization

Be careful, however, that you don’t use the absolute velocity number as a measure of team success. The goal is not to increase the number over time, but that it should aid in planning. Furthermore, also consider the velocity data as a rough heuristic measure. Since estimating Story points is not a strict science (and software engineering in general inherently has a lot of uncertainty), treat velocity with a grain of salt. For example, some tools allow you to enter a target velocity per iteration, and even account for team members taking a vacation by setting percentages of “full team capacity”. These calculations attempt to capture velocity as accurately as possible, which is unrealistic (because estimating story points is inaccurate), and also sets false expectations that the velocity data should be an accurate predictor of future engineering output. Chances are, one or two team members will be on vacation every now and then. Your team might also grow or shrink over time. Don’t obsess over these normal team dynamics. Look at your past velocity data with those events in mind when planning. The goal is to get to some rough level of consistency, indicating your team is getting better at estimating Story Points. But don’t fret if you see upward or downward spikes in velocity every now and then.

Don’t split Stories across Iterations

Relatedly, teams may get concerned that as they wrap up an Iteration, they may be in the middle of a Story. In this case, simply move that unfinished Story (along with any unstarted ones) to the next Iteration, or perhaps to some other planning backlog to be considered at a future time. Don’t worry about splitting that half-finished Story and trying to contribute part of those Story Points to the finished iteration. That’s simply too much trouble to attempt to get an accurate velocity number, which as we explained above, is not necessary, or even possible. That unfinished story’s points will contribute to the next iteration, and over time, everything will average out. There’s no need to split Stories.

Watch this video to get a step by step walk-through of how to create your first Iteration or read the blog post to learn more.

Leave a comment below and let us know how you're using Iterations or how we can make it even better.

‍