How To Plan An Agile Sprint

Micheál Clesham
By | Updated September 6, 2021 | 7 min read
Project Documents

In a previous blog post, we outlined the lifecycle of an agile project, from early conception to completion and review.

 

Start managing project tasks with a free SharePoint template

 

Here we take a microscope and look at the cycle of an individual sprint or iteration within the ‘Development’ phase.

Sprints or iterations set Agile apart from traditional styles of project management. Within each agile sprint, new capabilities are planned and delivered, by the end of the sprint, a new working piece of functionality is ready for use.

The combination of these sprints rapidly delivers more and more capability to the product over a 1-4 week cycle. In other words, each iteration should build towards adding specific value or functionality to the final product.

 

 

Agile Sprint Planning Meeting

A successful sprint in an agile framework is entirely dependent on two things:

  • The Goal: a specific measurable target of what the team plans to achieve within the sprint.
  • The Sprint Backlog: a list of stories, tasks, and items that the team has agreed to work on within the sprint.

 

These are both established within a Sprint Planning Meeting. This meeting should primarily involve the scrum master and development team. The product owner can attend but it is rare that outside stakeholders would attend.

Within a Scrum framework, the meeting should be no longer than 2-3 hours and ends with a strategic objective for the sprint (a one or two-sentence sprint goal).

This goal is achieved by reviewing the items on the product backlog and discussing which of these belong in the sprint backlog and why.

It is also important to take into account team capacity, skills, and any issues or risks that might slow progress.

The team will need to estimate the time required to complete backlog items, taking prior velocity from previous iterations into account.

Prior velocity is critical to scheduling the achievable amount of work and you should never use another team’s velocity to plan a sprint.

If the team hoped to achieve 30 story points in Iteration 1 but only delivered 25, then 25 should be the current velocity for Iteration 2.

Agile sprint planning works best when the team has a clearly defined, well-managed product backlog to start with. This reduces confusion and helps the team make informed decisions about which items to prioritize.

The best planning meetings allow the team to be creative, motivated, and challenged while setting realistic expectations.

 

Warning Signs

If the team keeps delaying or pushing the same features out into the future, it may signal an avoidance of certain key functionality and the causes should be investigated.

If the team is spending too much time on the details of each feature, they may be focussing on the work instead of the outcome. It is important to remind the team of the structure of a user story.

 

As <type of user>, I want <a goal> so that <a reason>

 

It is also advisable to have a product roadmap on hand along with the product backlog. This keeps everyone’s minds focused on the big picture of the overall project.

Remember that planning is only a guide to motivate and organize the team towards completing an agreed goal. The purpose is not to ‘account for every minute of the sprint’.

 

Adjusting the Iteration mid-cycle

If you have additional time left in the cycle, the team can request that stakeholders identify additional features or enhancements to that iteration.

If there is not enough time and the iteration cannot be completed as laid out in planning, then the team should work with stakeholders to identify which features can be delayed.

How you perform in your iteration will inform your next agile sprint planning meeting. Information on velocity and performance will help to generate better estimates for the realistic amount of work achievable.

 

Sprint Review and Retrospective

Sprint Review

The agile sprint review and retrospective is a meeting that follows the sprint and precedes the agile sprint planning meeting. This is a chance for the team to reflect and analyze how they performed in the previous sprint and provide critical information for the planning meeting.

The review meeting is often informal and usually involves a demonstration of the product for the product owner and stakeholders. This is not a status meeting and the presentation is intended to foster feedback and collaboration with all parties.

The review is often a good opportunity for the product owner to discuss and revise the backlog with the team. If possible it is also an opportunity to review timelines, budget, and potential capabilities.

 

Sprint Retrospective

The agile sprint retrospective is an opportunity for the team to analyze its performance in the previous sprint. The Retrospective is more structured than the informal Review, and focusses on the following:

  • What went well?
  • What could be improved?

Although issues can be flagged and improvements implemented at any time, they can be forgotten or unrecorded. The formal retrospective provides an opportunity to reflect and focus on adaptation.

The scrum master facilitates the session which should result in identified improvements to enhance collaboration, productivity, and enjoyment from the project.

Some teams like to allocate 3 hours and run the review, retrospective, and sprint planning meetings consecutively with short breaks.

This can be a timesaver as one meeting should naturally flow into the other but requires careful moderation from the scrum master.

Managing Sprints with SharePoint

Managing the Backlog

As stated earlier, a successful agile sprint-planning meeting is dependent on a well-managed backlog.  This is easily achieved using the Task List functionality within SharePoint.

Organize your task backlog by identifying the task type, including summary, sprint item, test case, or more. You can determine what sprint your tasks should be associated with.

You can also record the amount of work both planned, estimated, and actual work.

 

New backlog items can be added to the datasheet with as much information as possible at the time.

Finally, you can calculate the schedule using the in-browser scheduler.

 

Updating Sprint Items with Agile Boards

 

Boards are a prevalent feature in agile methodology. Boards are typically associated with Kanban but can be very useful for visualizing the sprint and updating items as work is completed.

BrightWork enhances the task list functionality in SharePoint with drag and drop boards that allow teams to intuitively update tasks and work items.

Boards in BrightWork can be configured to suit your process. Organize your tasks by teams or team members and move your cards into columns to update their status.

 

Agile Project Management Resources

Agile Boards for SharePoint On-Premises

Configuring SharePoint for Agile Project Management [Webinar Recording]

Managing a Remote Agile Team

5 Stages of the Agile System Development Life Cycle

 

Image credit 

Micheál Clesham
Micheál Clesham

Micheál is a SaaS product marketing specialist with BrightWork. For the better part of the decade, our in-house host has created engaging webinars and content with insights from Project Management Gurus and thought leaders. His go-to theme is Project Management best practices including project communication, collaboration and agile ways of working. Outside of work, Micheál likes to find new stories through podcasts, movies, sports, and travel.

Read Full Bio
Don't forget to share this post!