{"id":4739,"date":"2016-03-19T16:19:08","date_gmt":"2016-03-19T16:19:08","guid":{"rendered":"https:\/\/www.process.st\/templates\/sprint-planning\/"},"modified":"2024-02-28T16:42:02","modified_gmt":"2024-02-28T16:42:02","slug":"sprint-planning","status":"publish","type":"post","link":"https:\/\/www.process.st\/templates\/sprint-planning\/","title":{"rendered":"Sprint Planning"},"content":{"rendered":"
\n

Introduction <\/h2>\n
\n
\n <\/a>
\n <\/figure>\n<\/p><\/div>\n
\n

Sadly, even when user stories are standardized, assigned points and prioritized, you can't just take a clump and say "We'll do this lot in the next sprint". Books will be thrown, outraged letters sent to the papers and you'll be left with a wistful look in your eye for a set method in your sprint planning.<\/p>\n

'Planning helps an organization chart a course for the achievement of its goals... and determining the steps necessary to arrive at the intended destination<\/em>' - Brian Hill<\/a><\/p>\n

Well, we may have dramatized the reaction a tad, but in reality, sprint planning need only take two calls before your fortnightly sprints; one between software engineering and either your product team or owner, and another internal call within engineering.<\/p>\n

With this process you can not only get the sprint planning over and done with, ready to carry out the actual work, but you can eliminate any remaining confusion as to the importance of your tasks and level out a (realistic) workload between all of your developers.<\/p>\n

After all, there's no point in realizing the importance of aspects to your business like customer success<\/a>, if you then bottleneck your progress with a lack of sprint management (which will fix issues customers are unhappy with).<\/p>\n

Before you start, note that the main segments of this template ("Ordering the Backlog" and "Assigning the Backlog") should be carried out within your two calls. Check through them to get an idea of what needs doing, but only check them off when they are discussed live.<\/p>\n

All set? Let's get started!<\/p>\n<\/p><\/div>\n<\/section>\n

\n

Preparation: <\/h2>\n<\/section>\n
\n

Record the sprint's details <\/h2>\n
\n

First up, there's no point in carrying out the sprint planning process if you don't record the details of your sprint<\/strong> for future reference. After all, what would happen if you needed to roll your code back to the start of a problem, but lost track of when the issue began?<\/p>\n

Record the details of the sprint using the form fields<\/strong> below.<\/p>\n<\/p><\/div>\n

\n
\n