Everywhere I’ve seen agile used it seems to stutter and fail as people get tied up in process and bike shedding. That led me to think about how I’d like to run agile sprints.

So here it is:

  • There’s a ranked and ready backlog of tasks going into sprint planning. This will be a persons full time job. They’ll gather test data, acceptance criteria, and work with stakeholders to get the priorities sorted.
  • You’ll have short refinement sessions where the team helps with breaking tasks down and pointing them. Having some archetypal tasks to point against is useful.
  • Don’t split hairs when pointing stories. If in doubt use the higher score.
  • Only commit to as many points during a sprint as your velocity indicates you can complete[0].
  • During the sprint you’re allowed to bring in extra tasks if you’ve finished everything already or you are reasonably sure it will get finished in the sprint.
  • At the end of the sprint update your sprint velocity and reflect on how well you pointed.

And on the subject of agile ceremonies:

  • Daily stand ups should be short and sweet. Each person says what they did yesterday, what they’re doing today, if they need any help. NO TECHNICAL DISCUSSIONS.
  • Have somewhere mid sprint to log your thoughts for retrospectives rather than having to think on the spot during the meeting.
  • Time box your meetings. Keep them snappy.

That’s pretty much it. The core idea is that it’s a feedback loop and you’ll improve your process over time. In the beginning don’t be afraid to put fewer tasks in. It’s really nice to get some early wins.

If you end up being interrupted by emergencies, leave some slack in your commitment. You can fine tune a point value for this slack over a few sprints.

That’s it. It’s lightweight and tool agnostic. Adjust stuff you feel needs adjusting but not before trying it just a little bit.

[0] - Fundamentally you want happy stakeholders. When you commit to a sprint you’re promising to stakeholders that this set of tasks will get done by the end of the sprint. You want the default outcome of each sprint to be a success. What you do not want to to over promise and under deliver, especially on a regular basis. You want your stakeholders to have faith that you as a team can deliver what you say you can. If sometimes you slip they’ll be more forgiving than if you consistently miss targets. Hell, the opposite is will also be true sometimes! You might finish all the tasks you committed to and you delivered a few extra on top.