How to plan and execute your most productive sprint yet

Photo credit: William Iven

Planning a sprint can be a minefield of poor estimations and unforeseen setbacks, along with a serious danger to lose context to the important long-term goals which need achieving. However, 2 week sprints can bring a huge amount of flexibility and productivity to the table.

That is, if they are planned and executed correctly. After all, you don’t want to have your management methods being labelled as some sort of horrific agile cult, right?

A sprint shouldn’t stifle the creativity of your kickass developers or (heaven forbid) inspire a death march to hit deadlines and achieve this number of estimated points. Instead, these objectives can be achieved and double-checked naturally by using the following steps.

Remember to explain this process during employee onboarding, just to make sure that everyone’s on the same page!

Groom your user stories carefully

Any developer (or project manager, for that matter) should know how to groom a user story, so far be it for me to tell you what you already know. However, you should ensure that all stories are being groomed and tracked using a regular process and high quality tool.

For example, at Process Street, we’ve seen success using the agile naming method (“As a user, I want to… so that…”) and using JIRA to track the stories. Much like the “agile cult”, JIRA has its share of value debate, but if used as more of a sticky-note board on which your stories can find a home to be later sorted and easily found, you can work wonders with this tool.

Bugs and feature requests are submitted either through what’s learned from conversations in customer support or by employees directly, with links to any relevant support conversations in the story. This doubles up by showing how much the story has been requested, due to the number of support conversations linked, and provides a more immediate response for a better customer support experience.

There is one thing to remember above all recommendations of layouts and tools, however. Whatever method you use, you need to make sure that it is standardized.

Don’t assign any old points

Much like grooming user stories, the process of assigning points to your chosen issues is familiar to many. However, a great deal of project managers run the risk of misunderstanding the point behind these… Well, points.

They aren’t an estimation of how long you want a project to take; they’re an indication of how long it is expected to take. It’s not necessarily the end of the world (or even the fault of the developer) if these points aren’t achieved.

Still, in order to get the most accurate measure you can, make sure that you don’t estimate points based on one person’s opinion (no matter how experienced they are). Instead, use a tool such as PlanITpoker to cast a vote.

Prioritise, but stay in context

Get communicating and collaborating

Manage your resources in worst case scenarios