Agile Sprint Planning for Designers - Basic Concepts, Jargon, and How to Start
January 30, 2017 • 6 min read
January 30, 2017 • 6 min read
In my last post, I discussed why designers should be working in agile sprint planning. Today, I’m explaining basic concepts, terms, and how you and your design team can start working in agile sprints.
A sprint is the duration of time for which you will plan a set of work. We use 2-week sprints here at SendGrid because it’s a long enough window to keep planning meetings manageable but short enough that we can stick to our plan without that plan shifting underneath us.
A story (or user story) is an agile term for a piece of work that you want to do. I encourage our teams to create stories not just for actual work (designs, research, asset slicing) but for other time-consuming activities like half-day team building events, interviewing, personal objective work, vacation days and holidays.
An estimate is how much effort (a proxy for time) a given story will take for you to do. For developers, having a relative point scale (such as Fibonacci) for estimates is recommended. For our design teams, we cheated a little bit and came up with a more time-based estimation scale. It works really well for us:
1 = 1 minute – 2 hours
2 = 1/2 day
3 = 1 day
4 = 2 – 3 days
5 = 4 – 5 days
"I encourage our teams to create stories not just for actual work but for other time-consuming activities like half-day team building events, interviewing, personal objective work, vacation days and holidays."
Before you assign an estimate, take the time to really think through the full scope and requirements of the work. For example, what sizes and formats of the design will be needed? Does the design need copy editing? Do you need to investigate and purchase a new font? If you find that your requirements and goals are unclear, or you’re missing a prerequisite, loop back with the stakeholder to fill those gaps in before you consider adding the work into your sprint.
Once you have thought through the scope and estimate for a story, it’s time to scrutinize each story for overstuffing. Stories that pack in a lot of scope–in our case, a story with an estimate of 4 or higher–can derail your sprint because they keep unfolding as you dig into them. Break these overstuffed stories into smaller, discrete stories so that you can compartmentalize the risk and get the satisfaction of finishing stories quickly within the sprint.
A backlog is a set of stories that you plan on doing at some point, but have not yet been planned into a sprint. Backlogs are a great place to store requests as they come in from stakeholders so nothing falls through the cracks. It’s also important to be proactive in building your backlog. Reach out regularly to stakeholders on what needs they have on the horizon so that surprises don’t come in at the last minute.
Once you have a backlog of stories and estimates you can start to prioritize them. This is where deadlines (such as an event or product release) become important inputs. Outside of hard deadlines, it’s critical that you reach out to your stakeholders to understand their relative priorities.
Let’s say you now have a prioritized backlog of 30 stories. The fun part is figuring out which of those stories will actually fit into your next 2-week sprint. This is where your sprint planning meeting comes in. The day before or the morning of the first day of your sprint, you’ll want to meet with your stakeholders for 30 minutes to an hour to build your sprint plan. You’ll add stories to your sprint based on their priority until the total number of story estimates is equal to your historical velocity. When you’re first starting out, consider adding 2-3 small placeholder stories for the last minute requests that will continue to come in while you establish your new process.
A best practice is to pull averages from your last 3 "normal" sprints.
Velocity is how much work you can fully complete in a sprint, at high quality and without working nights and weekends. A best practice is to pull averages from your last 3 “normal” sprints. We track velocity by both average story count and the average total of estimates. If you’re just starting out, you won’t know your velocity, so you’ll need to make a conservative guess. If you run out of work, just add 1 story at a time until the end of the sprint. This is preferable to planning too much work and having to remove it or defer it to the next sprint.
If you’re using a tool to track your work (which I highly recommend), such as Jira, Trello, Pivotal Tracker or CA/Rally, then as you begin work on something, you’ll be able to move it through different statuses that represent where it is in its lifecycle. Our board has 4 status columns: Open, In Progress, Review, and Done. The Review column is critical to our design team because virtually every story we do has an output–a design, a wireframe, a research summary, a research test plan–that needs review from stakeholders or teammates. The review column ensures that designs aren’t considered “done” until they’ve had additional eyeballs on them.
Once you have your tooling, sprint, and backlog ready, it’s time to have a sit down chat with your stakeholders about your new process. At first, they may feel uncomfortable with the idea of having you “locked” into a set of work. It’s not easy for stakeholders who are accustomed to fly-by requests to starting planning out their needs by a couple of weeks. Add recurring reminders to your calendar to reach out to stakeholders about upcoming projects to help break the habit of ad-hoc requests. Set clear expectations about your new process and the time that it will take to establish your velocity.
When you’re ready, hold your first sprint planning meeting. Discuss each candidate story to ensure it’s truly ready to be worked on, confirm priorities, and be very firm about removing work that exceeds your average velocity. Having a conversation about tradeoffs is tough but one of the most important aspects of the entire process.
After just a few short sprints, you’ll be able to meet stakeholder needs even more effectively than before and you’ll finally be free of the chaos! Still not convinced? Check out my previous post which breaks down why designers should be working in agile sprint environments.