How To Prepare Your Team For Sprints In 5 Easy Steps

No Matter How Agile You Are, You Can Start Sprinting Today

Are We Ready To Run? Let’s Prepare For Sprints.

A sprint is a period of time (typically two weeks) where work is allotted and completed for review and/or revision. Sprints are beneficial in software development because they allow for changes to be made as work is being done, rather than after you have completed an entire project. This can save you time, money, and help manage expectations in the success or failure in delivery.

Step 1: Enhance (Or Fix) Communication

First, you need to take a look at how you’re currently communicating, and compare it to how you would like to communicate moving forward. Starting with communication is crucial, as that is the foundation for all of the agile principles.

Update your meetings to match scrum ceremonies for the appropriate touch-points. Start with taking a ‘meeting inventory’ inclusive of any repeat agendas. Include details such as day/time, invitees/organizer, agenda (if applicable), and desired outcome. It’s important that your meetings remain outcome-oriented so as to avoid unnecessary conversations.

The primary meetings you should be looking to add is some kind of regular stand-up (daily, every other day, etc. — this may vary per team), a sprint planning meeting (to review in-flight, upcoming, and ad-hoc work), a backlog refinement (also known as grooming) meeting (for confirming details and group estimation — see more below), a solution and design review meeting (to align on solution approach, root cause, or design elements), and optionally, a retrospective (to review team feedback) and demo meeting (to preview work completed). Demos can be optional as they are not required in order to prepare for sprints, and may vary in importance depending on your deployment process, however they are highly recommended for constant visibility.

Only invite attendees who add or obtain value, and avoid adding managers or stakeholders to your retrospectives. Be sure to create strict agendas for these calls as to not sidetrack or run outside the allotted time. The length of these meetings will vary, however, they should range from fifteen to thirty minutes long, and should never take longer than one hour. It is better to have two thirty-minute meetings per week than a single one-hour meeting.

Step 2: Refine, Define, and Outline

You can’t expect work to be solutioned, estimated, or planned without first uncovering all expectations and requirements from the business. Oftentimes, the most bottlenecks within software development teams come from lack of ownership and/or definition on the product/business side. First, you’ll need to refine what you have in your backlog. Take thirty minutes once or twice a week until you get through everything — skipping this step will not set your team up for success when it comes time to execute.

In order to refine your backlog, you must make sure each ticket meets your pre-determined definition of ready for estimation. This often includes a user story, acceptance criteria, and sometimes environment or applicable test case. Ensure you have a designated product owner or similar role solely responsible for writing these to cultivate consistency in your requirements.

In order to define your work, you must ensure your tickets are organized. Are you grouping by feature, epic, or story? Are you relating those to size in any capacity, or just using them to group?

Lastly, to outline your work, it is important to include problem and impact, potential solution or design, and desired outcome from the business to be evaluated by the engineering team. Without the problem statement, the engineer might create a solution that doesn’t fix the underlying need. This should include both the business/product team for clarification and any members of the engineering team for consensus and/or applicability.

Step 3: Upgrade Your Estimation

What does it mean to give a purposeful estimation? It’s easy to throw around numbers to check off that box, but where is the value? A purposeful estimation is one made with certainty, taking in all appropriate factors, and ensuring the number is tangible to a metric or value-add.

Make sure your tickets have consistent estimation. At this step, it doesn’t matter if you’re estimating in hours, t-shirt sizes, or story points — all that matters is an estimate is present and consistent throughout your entire backlog. If you’re new to estimation and don’t know where to start, we can help! Email support@mediatriton.com for free personalized advice. You’ll want your entire backlog (or at least the majority of your foreseeable work) estimated before you begin your sprints.

Establish Estimation Process (Get Ahead!)

Your goal should be to have a full two-sprint buffer. This means that, excluding your active sprint, you have two upcoming sprints fully planned and estimated. These plans should not be touched unless a higher-priority task or critical bug arises. Generally, the business should have an understanding of their needs enough to have the next month (with a sprint being two-weeks) of work planned accordingly.

First, we need to make sure our entire backlog (to the best of our ability) is fully defined and estimated.

Start with the work you have in-flight, as your team should already have a good grasp of those ticket requirements. Use a fun game like planning poker either digitally or in person to make sure everyone participates. Planning poker allows your team to anonymously estimate tasks and then collectively agree on a number post-discussion. This allows for shared visibility among technical and non-technical teammates, related tickets, features, or alternate work types.

These estimation meetings should occur as often as possible until your entire backlog is estimated, after which the frequency can be diluted. Your goal is to have every ticket in your backlog estimated by your whole team, so make sure no one is excluded from these meetings. Once your team gets into a good groove with estimation (this can take anywhere from 2–10 sessions), you should be able to normalize your velocity within 3–5 sprints.

Once all work is defined and estimated, this means it meets the definition of ready for work, and you’re ready to plan!

Step 4: Begin (Loose) Planning

What’s the difference between a plan and a loose plan? It can be intimidating to start ‘planning’ your sprints depending on how much work you have, so take the pressure off. Allow yourself to create a high-level plan with the intention to review and adjust as time goes on.

Create multiple empty sprints in your backlog. These can then be manually populated by whomever owns the business requirements. The most important factors to take into consideration while planning are the task’s priorities, any team or work dependencies, and critical deadlines.

Leave room for in-flight work (ie. current work in progress) that may roll over by choosing a starting velocity. If you’re starting off with zero estimation, use the number of tickets in your sprint. Start with two tickets per person — it’s always better to add more tickets than to have too many, as it helps you grasp your capacity faster and more transparently. If you’re using an estimate already, but don’t have a stable velocity, you can do this by utilizing the two-points-per-person rule or reduce your current velocity by 50–75% depending on how much does/doesn’t get completed sprint-by-sprint.

WAIT — What Do You Do With Current In-Flight Work?

We are going to put all current work-in-progress into our first sprint bucket. This is where our chosen velocity comes in. Our main goal is to take however many tickets we have in our sprint, and divide them across our future empty sprint buckets. Here is where we must look closely for blockers, dependencies of any kind, priorities, and due dates.

Step 5: Understand Impediment Traps

Blocked work, due to a dependency from a team or ticket, can be really difficult to navigate.

Paused work, meaning tickets that are put on hold until further discussion, input, prioritization, etc. that are not blocked (meaning, no intention yet to resume), should be immediately moved to the backlog for further evaluation with applicable parties outside of the current sprint.

Revisions, changes, or bugs within current work, sent back for any reason should be evaluated with the current requirements and estimate in mind. Ask yourself if the changes or issues were expected within the requirements or estimation value. If not, the ticket should be moved to ‘blocked’ and a new ticket should be created to resolve. This will help keep tickets from ‘sitting’ without understanding of what or why.

Revisions, changes, or bugs after work is completed or deployed should always be created into new tickets linked back to the original for further evaluation, definition, and a new estimate. This will help ensure your velocity is accurate and your metrics are not disrupted by confusing back-tacking.

Helpful Tips

Organization: Clean out any pre-existing sprints that are no longer relevant. Try to group by epic when you can to keep stories action-oriented.

Workflow: Leave blocked or paused tickets in the backlog, and only move them into the sprint if they become unblocked.

Velocity: If you have issues with ad-hoc work, leave room in your sprint for any critical or unplanned tickets that arise. You can constantly allocate a certain percentage (depending on frequency and team availability) to sporadic work to ensure it fits into the sprint without disruption to your velocity, and pull in other lower-priority tasks to fill that time if not utilized.

Once You Kick Off…

Continue to inspect and adapt throughout every sprint. Make the most of your retrospectives and gather meaningful feedback on your processes, sprints, and interactions. End every retro with a list of action items and a plan to tackle them. Remember, there is no right or wrong way to work in sprints — do what makes the most sense for you and your team.