Sprint Planning. Guidelines

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, physical, or something more abstract.

The whole Project scope is managed better when small chunks are planned periodically. Like the work breakdown structure (WBS), these small chunks (epics, stories, tasks) better fit the timeframe equal to weeks or months the most. This is what we call Sprints.

Sprint Planning is iterative and timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Sprint Planning initiates the Sprint by laying out the work for the Sprint. This resulting plan is created by the collaborative work of the entire Team.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Team may also invite other people to attend Sprint Planning to provide advice. They are subject-matter experts.

Guideline

1. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Team may refine these items during this process, which increases understanding and confidence.
2. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, upcoming capacity, and Definition of Done, the more confident they will be in their Sprint planning and forecasting.
3. For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
4. Any task tracking system can be used to visualize planning activities. It encompasses:

• resources evaluation: — people availability (vacations, sicknesses, onboarding), — tools availability (tools needed to reach the Sprint goal), — capacity for the Sprint
• priorities revision;
• task estimation;
• people assignment;
• discussion and possibly: — resolving dependencies, — ambiguous requirements, — saying “No” to items that cannot be completed.

The Definition of Done (DOD) provides a checklist that usefully guides pre-implementation activities: discussion, estimation, and design. It limits the cost of rework once a feature has been accepted as “done”. An explicit contract limits the risk of misunderstanding and conflict between the development team and the Client.

Sprint forecasting helps to refine items for the next planning meeting.

Even in an agile environment, it helps to plan in advance and see the dependencies, and coming-next items, and align expectations.

For a better understanding of what is being planned, a project manager can divide the future scope into following categories:

• New Features
• Change Requests & Enhancements
• Refinement & Tech debt
• Support & Bugs

The more precise estimate is given a better understanding of the forecasted volume.

Priorities are set as follows

• HIGH — the task is required to be done in the planned Sprint
• MEDIUM — the task should be done in the planned Sprint but not as the very first item to focus on
• LOW — the task should be done in the planned Sprint but is the first item to swap with when other tasks with higher priorities come

Visuals

For better visual orientation the cells can be colored as well.

Must-have item | Needs clarification | Blocked item | Design

• Must-have items are items that cannot be carried over to the next Sprints.
• Needs clarification are vague, unclear tasks where the Product Owner’s input is required
• Blocked item is usually dependent items and should be addressed as soon as possible
• Design means the items must be groomed and designed before the coding

It is recommended to have a continuous process of forecasting to enhance the Planning meetings.

DevCom is a trusted technology partner for many of the world’s leading enterprises, SMEs and technology innovators. Through every stage of the product life cycle, DevCom is a brain-trust dedicated to forward-thinking.

In case you don’t know where to start your project, you can get in touch with us.

Our Blog: https://devcom.com/articles/