Sprint plan setup

Explore using different estimation techniques such as t-shirt sizing or story points. Different techniques might provide different views of the problem. A good sprint plan motivates everyone by defining an outcome and a clear plan for success. But be careful planning too upfront. Next, ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.

Scrum is a process framework aimed at solving complex problems. Complex problems require an empirical process learning by doing. Instead, focus on the outcomes and get going. It does not have to be hard, even if the problem you are solving is.

Ready to start? Learn how to use sprints in Jira Software. Dave West is the product owner and CEO at scrum. He is a frequent keynote at major industry conferences and is a widely published author of articles and research reports. Reach out to Dave on twitter DavidJWest.

A step-by-step guide on how to drive a scrum project, prioritize and organize your backlog into sprints, run the scrum ceremonies and more, all in Jira.

Learn how to facilitate great agile ceremonies like sprint planning, daily stand-ups, iteration review and retrospectives.

Agile Scrum Sprint planning. Sprint planning Sprint planning is an event in scrum that defines what can be delivered in the upcoming sprint and how that work will be achieved. Dave West. Browse topics Agile manifesto. Sprint planning. Sprint reviews.

Scrum master. Distributed scrum. Scrum of scrums. Agile scrum artifacts. Scrum metrics. Jira Confluence scrum. WIP limits. Kanban vs Scrum. Project management intro. Epics, stories, themes. User Stories. Gantt chart. Program management vs. Product Roadmaps. Product Manager. Tips for new product managers. Tips for presenting product roadmaps. How to prioritize features using NPS. Product analytics. Remote product management. Managing an agile portfolio. Lean portfolio management. Long-term agile planning.

What is SAFe? Spotify model. Organizational agility with Scrum Scale. Scaling agile with Rosetta Stone. Using Improvement Kata to support lean. Agile iron triangle. Beyond the basics whitepaper. Dev managers vs scrum masters. Is there new information to consider? Are estimates for the story still valid? Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal.

Once the definition of the story is fixed, it must be broken down into tasks. Some of these tasks will become user stories in their own right. The team will decide what specialist skill sets, if any, are needed to handle these tasks, and will also ask how to test the story.

Tasks and user stories that are moved to the sprint backlog will be assigned due dates, taking into account the number of working days and whether any team members are going on holiday or will be working on the Scrum team part time.

But, how does one decide how much space each backlog item gets? Another is to connect bug fixes to user stories and then size and prioritize them like user stories. Lastly, the Scrum team, Scrum master, and product owner will create a definition of done, including some sort of testing metric to help ensure the quality of the new iteration.

Ideally, the sprint planning session will conclude by having met some target outcomes. Many marketing teams are also enthusiastically embracing Agile. Of course, marketers have no fixed iterations of software to release.

What they do have are ongoing often long-term projects that comprise a variety of activities. They need to constantly juggle priorities over the short and medium terms, often with a clear objective in mind for each new set of efforts.

So, for marketers, adopting Agile methods is a way to be able to react in a coordinated manner to changing market conditions while maximizing efficiency and moving toward a clearly stated goal. For the most part, sprints and sprint planning for software development and marketing are very similar. There are a few significant differences, however.

For one thing, the length of marketing sprints tends to be shorter than that of software development sprints. The typical marketing sprint does not take longer than two weeks, while in software development, sprints lasting one or two months are not uncommon.

Second, changes to the sprint backlog during the course of the sprint are more common in marketing than they are in software development. This difference relates to the more rigid constraints imposed by the technical tasks involved in software development, while marketing lends itself to being more fluid. Third, there are likely to be more wide-ranging specializations in a marketing Scrum team than in a software development Scrum team, since the former encompasses more disciplines.

Experts recommend some best practices to get the most out of your sprint planning meeting. When sending out the invite for the meeting, include the agenda. Also, consider adding a link to the candidate user stories from the product backlog, so the developers have some time to peruse them before the sprint meeting.

This is because the Scrum master and Scrum team are likely to reject some user stories or postpone them for a later sprint. Like the Scrum team, the product owner is more of a contributor to the meeting: Product owners answer any questions the developers have, explain user stories, and negotiate acceptance criteria under the mediation of the Scrum master. The product owner, for example, takes the lead in creating the sprint goal and is responsible for defining the scope of the sprint, extensively detailing each user story — complete with a definition of done — and prioritizing the product backlog.

The Scrum master arranges the logistics of the meeting and negotiates key metrics, like sprint velocity and practical team capacity. They also take the lead in finalizing the sprint backlog and moderate negotiations between the product owner and the Scrum team.

The Scrum team collates whatever information it needs for the upcoming sprint and commits to a sprint backlog it knows it can reasonably deliver. One common source of dysfunction in sprint planning, says Agile coach Kevin Brunner , is the person in charge of the backlog. Visualizing : Fast-forward to the end of a sprint with a successfully completed iteration and work backwards from there to negotiate acceptance criteria and extract the information needed to deliver the completed iteration.

Visualizing gives the team the a concrete end product around which its efforts will coalesce. Cultivation also allows the team the time it needs to make decisions, and ensures buy-in to key aspects of the sprint, such as the scope and time estimates. Here are the most frequently asked questions regarding sprint planning:. How are dependencies between tasks best handled?

There are several ways to mitigate the potential time-wasting effects of task dependencies. First, task planning during the sprint planning meeting can actively minimize or eliminate complex dependencies as you break down user stories into tasks. Second, you can build buffer time between dependent tasks where possible. Third, the use of loosely coupled, adaptable designs and development techniques, such as mock objects , can help developers cope with the effects of dependencies.

And, fourth, having developers work in proximity to one another can preempt dependency-related problems by facilitating communication. How much should each team member sign up for?

How are iterations planned if team sizes vary? While recurring changes in team sizes are not ideal, they are sometimes unavoidable. If the size of a team changes, compute the average number of story points tackled per developer in the last sprint, and multiply it by the number of developers participating in the upcoming sprint to obtain a ballpark figure for sprint velocity. You may have to further adjust this figure based on exactly who is leaving and joining the team.

How is overhead, such as time spent in meetings or writing emails, accounted for? There is no rule of thumb for calculating overhead, since it varies from team to team. Most teams simply assume that a consistent length of time is spent on overhead in each sprint and that the sprint velocity of previous sprints accurately reflects time spent on overheads. How should bug-fixing be accounted for? There are a couple of ways to approach this. One is to treat bugs as user stories, estimating the amount of work involved just like for other items on the sprint backlog.

Another, riskier approach is to not assign story points to bugs, which lowers the team velocity. The risk of this approach is that it only works if you perform the same amount of work on bug-fixing in each iteration. If the amount of work on bug-fixing varies, the velocity will change drastically from sprint to sprint, making planning for future sprints much more difficult.

Why should iterations always be the same length? The answer, in a nutshell, is rhythm and consistency. The sequence of a sprint proceeds much more smoothly if it follows a regular, easily predictable cycle, which greatly simplifies sprint planning.

How is time spent on testing and documentation accounted for? The easiest way to do this is to include time spent on testing and documentation as a separate task for each user story. An alternative is to create a separate item on the sprint backlog for testing and documentation. Should feature estimates be revised during iteration planning?

Only if the original estimate is wildly inaccurate. Should task estimates be revised during an iteration? Of course, the Scrum master will likely make a note of why the team chose to change a task, so they can reflect this information in future sprint planning.. Should all teams operate on the same iteration schedule?

This depends on the number of Scrum teams working in tandem and the availability of supporting staff. If there were no constraints on having multiple teams work on iterations that started and ended at the same times, the resulting synchronization would be of great benefit for management. It would reduce the risk of one team's work forcing changes onto another's sprint backlog, since teams would coordinate with one another regarding their sprint planning.

In practice, however, Scrum teams do not work in isolation, and there are a limited number of people who fill supporting roles across multiple Scrum teams and appreciate iterations with staggered start and end dates. If, however, the same features are being pushed repeatedly into the next sprint, the team is likely deliberately avoiding tackling certain user stories or bug fixes. This situation merits an exploration of whether there are issues around these user stories or bugs that are not being raised during sprint planning.

A failure to complete the sprint backlog could also point to overdesigning, which is a case of the developers going above and beyond in their work, effectively doing more than is necessary. A sprint planning session can be sabotaged by some common pitfalls:. It reduces both their engagement with the planning process and the likelihood that the sprint will meet its stated goal. A sign that this problem may be looming is not having all the items on the sprint backlog split into a series of manageable tasks.

A very complex task is not a big enough multiple of a simple task. How will your choices now on what to build impact your next sprint or the one after? Any planning session will benefit from a big of foresight.

So why bring them stories that are dated, disorganized, or unclear? A minute product backlog grooming sessions helps fill in the blacks on user stories that are lacking detail or context from you, the product owner. This means making sure each story:. Planio—our project management software—offers a few unique features that can help speed up your grooming process.

First, you can create categories for issues, which will allow your team to quickly see the kind of work each task involves. You can also use sub-issues to break up larger user stories into the individual technical tasks needed to see them to completion and connect relevant tasks and stories together.

This including a proper description, priority, status, estimated time, and even acceptance criteria. One tip from the team at Software AG is to use checklists for acceptance criteria. This way, during a sprint review meeting, the customer or product owner themselves can tick off the criteria. Lastly, you can start planning a new sprint with one click using the Sprint planning button in the sidebar. Simply name your new sprint, set the start date, and drag freshly groomed backlog issues into it.

One of the most difficult parts of proper sprint planning is being able to estimate how long tasks will take and just how much can get done during your sprint. Agile coach Mike Cohn uses the example of two runners talking about how long a 5km race would take to run.

One says 25 minutes, while the other says Regardless, they can both agree that 5km is shorter than a marathon. The what is your Sprint goal : Simply put, what you want to have delivered by the end of the sprint.

Above all, your sprint goal needs to be realistic based on the scope of work and the size of your team. As ultimately, it will be what the success of the sprint is judged against during your sprint review. Not the individual tasks and stories completed.

This is the amount of work that typically gets done in a sprint of the same length as well as any factors that might influence it, like vacations, public holidays, or other interruptions. Instead, the team should come together to discuss what can be done so everyone has buy-in.

Next, the how is your Sprint backlog : the list of user stories that will need to be completed in order to achieve your sprint goal. Trust me, I know.