Agile Sprint

Agile Sprint

At the core of Scrum is the Sprint; a container which holds all the other Scrum events together. A Sprint is bounded by time, in most instances 2-weeks but no more than one month in duration is the recommendation.

My preference has always been to run 2-week sprints, things change rapidly and any planning beyond that time-box becomes hazy. Plan so you can see your horizon, beyond that you’re guessing and likely to create redundant work for yourself as you pivot based on changing requirements. Also, it’s much easier for your team to plan and visualise over a couple of weeks, and most find it more manageable, accurate and less overwhelming psychologically.

Shorter Sprints also help with budgeting as you limit any overspend risk, to a maximum of one calendar month, should you do need to pivot unexpectedly. 

During the Sprint

The Scrum guide specifies that within the sprint:

  • No changes should be made, that would endanger the Sprint Goal; 
  • Quality goals do not decrease; and, 
  • The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. 

Now, there are some caveats to these rules, in particular, to answer the question: “Can I add new work to the Sprint once it’s started?”

It is possible to add work to the Sprint, if the development team approve it, and if it doesn’t compromise the original Sprint Goal and deliverables. The Development team owns the Sprint Backlog, the Product Owner has responsibility for the Product Backlog.

A Sprint can be Cancelled

In very rare circumstances but it is possible to cancel a sprint, but I don’t promote the idea. If the Sprint Goal becomes obsolete; if technology conditions change, or the company changes direction within the market. A Sprint should be cancelled if it no longer makes sense given those circumstances. However, keeping Sprints to a couple of weeks should mean you never need to cancel one.

Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. 

What happens if a Sprint is cancelled?

If a Sprint is cancelled, any releasable, “Done”, items should be reviewed by the Product Owner to see if they are acceptable and any incomplete items should be re-estimated and put back into the Product Backlog. Don’t assume they simply go into the next Sprint because it’s business value may have changed and you’ll have to re-prioritise those tickets against the other requirements.

Scrum Events

As I mentioned earlier Sprints consist of four events: Sprint Planning, Daily Scrums, the Sprint Review, and the Sprint Retrospective. I also use one additional event myself, which I’ll discuss later.

A new Sprint starts immediately after the conclusion of the previous Sprint, it’s a continuous effort. You always feel like there would be a pause to catch your breath a short break while you get ready, but what you realise is it’s like raising a baby – there are no breaks and you simply have to get used to the baby’s routines.

The purpose of the agile scrum events is to provide opportunities to inspect and adapt development work and also provide transparency for the team; the three pillars of Scrum. See each of these events as opportunities to review and communicate with the Scrum team. Don’t remove any one of them, learn the benefits of each.

Visual-paradigm’s 3 pillars of scrum visual

Scrum events create regularity and help to reduce the need for long and frequent meetings and the Guide provides guidelines on a recommended duration for each event. As my team’s got we could complete our Sprint Planning sessions faster, by also using the Sprint Retrospectives to improve our processes and refine communication and grooming. The guide will state that for a 2-week sprint you should plan for a 4-hour meeting, if you run a month sprint then it’s recommended to have an 8-hour meeting. That is a lot of time for your entire development and scrum team to be in meetings and not always the most cost-effective way to spend your budget.

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. So shorter sprints will allow you to pivot earlier saving development costs and allowing you to launch features that will bring a return on investment sooner.

Start with a Sprint Goal

Each Sprint should have a Sprint Goal; an achievable outcome, a focal point for the development team, on the purpose of the Sprint and what is to be built, and the resultant product increment. 

Sprint Backlog Grooming review

Now, this is an event not in the guide but one I have used successfully and one I’d recommend you consider; it’s a Sprint Backlog Grooming review. I hold the review meeting a couple of days before Sprint Planning, it can take between 1 or 2 hours to complete. Attendees include the business stakeholders, business analysts and the event is organised by the Scrum Master. The purpose of this meeting is to plan for the upcoming Sprint with internal stakeholders to ensure the business value of the tickets chosen for the next Sprint are still valid and they are to proceed. It’s good communication to ensure the entire internal team is on the same page before going into Sprint Planning. There is nothing worse than senior business stakeholders starting to query tickets in Sprint Planning in front of your development team. They’ll throw the event off on tangents and undermine the product owners authority.

So use a Sprint Backlog Grooming session to provide that safe zone for these discussions. The development team is free to join and we may include them if we want to discuss a future story in more detail, but I use this a chance for internal stakeholders to discuss their requirements.

As a Product Owner, I’ve also embraced the concept of being a servant-leader, I can’t know everything and I have to rely upon the experts around me for advice and direction at times. That’s how we all come together as a team and build great products.

Some will say this is wrong, but the reason I introduced this to allow the internal stakeholders the chance to discuss and agree on their top priorities for the next sprint. I could also ensure tickets were fit for review before going to Sprint Planning.

Sometimes tickets will need further refinement, explanation or acceptance criteria. In large teams, tickets will be produced by business analysts, customer support and the BAU production team, and not always through the product owner. It’s a chance for internal stakeholders to discuss their needs and be questioned about the priority or business value, without them being called out in front of the full team. It allows everyone to be heard and respected.

These internal discussions can become quite heated, with stakeholders arguing for position, grandstanding and berating the slowness of delivery. Some department heads are notorious for using this valuable time to use their power to try and influence decision-making and undermine the product owner’s authority.

I don’t find it productive for the development team to hear this or to be in attendance at those sessions. So I give the stakeholders their opportunity separately, which ensures when we hold Sprint Planning that session goes so much smoother; with fewer interruptions, no arguments in front of the team, and total focus on the development team, backlog and the sprint goal.

TIP: Product Backlog grooming is best undertaken before each Sprint starts, and you should be refining, adjusting and prioritising the next Sprint while one is in development. Product owners should keep on top of it constantly because Sprint Planning has a habit of coming around very quickly. Also, don’t do the grooming in isolation, discuss items with stakeholders, business experts and the development team too.