BROADCASTS.com

Today Dan Neumann will be focusing on the topic of getting to \u2018done\u2019 within a sprint.

Getting an increment to \u2018done\u2019 is really challenging \u2014 even for Scrum teams that have been working for a while. So it is especially challenging for folks that are new to Scrum and sprinting all together. Even at the longest duration of a sprint (which is one month), it can fly by incredibly fast! So if you\u2019re used to really long delivery cycles with long requirements, think about how fast a two-week sprint will go!

\xa0

So how might we get to a done increment? Tune in to find out!

\xa0

Key Takeaways

What does it mean to get \u2018done\u2019 in a sprint?

In the Scrum Guide, it says that the increment must be done and in usable condition

The team ultimately decides what \u2018done\u2019 is (but it does need to be in usable condition)

What do we not want to do to get to \u2018done?\u2019 What methods \u2014 though, often posed \u2014 simply do not work?

Nailing the requirements up-front so they\u2019re moving because it\u2019s easier to hit a static target than a moving one

Building within the sprint and then testing within the next sprint (which is a non-option because within each increment it should be in a usable condition)

Build for seven days, do a code freeze, and then test for three (which is ineffective because you end up with questions such as: \u2018What did the developers do for the last third of the sprint?\u2019 And, \u2018What do the quality specialists do for the first two-thirds of the sprint?\u2019 etc.)

Implementing \u201cWagile\u201d (Waterfall-Agile), where you nail the requirements and then iterate through the delivery of the requirements through the sprint

Extending the sprint because the work isn\u2019t done (this is the best time to stop and have a retrospective)

Dan\u2019s recommendations for new teams looking to get \u2018done\u2019 every increment:

As a Scrum team, collaborate to break your product backlog items down into smaller pieces (small batches are going to move through the sprint faster, and a smaller product backlog item will get delivered more quickly than a large product backlog item [it\u2019s far more valuable to have 9 things at 100% and 1 at 0% than to have 10 backlog items at 90%])

Make sure that everyone on the team is really focused on quality

Really maximize the amount of work not done; ruthlessly focus on meeting the acceptance criteria for your product backlog items and no more than that

Pull your testing forward

An activity that can be super valuable for Scrum teams is to have a subset of the team (representing quality, development, and the product owner) to get together and define what the test cases are that are ultimately going to have to pass

Look for tools to support the people and interactions \u2014 tools can really help your Scrum team move forward rapidly (tools that can automate the unit tests that need to execute are especially beneficial)

Encourage more self-organization and look for ways to increase more collective code ownership within your team (activities like paired programming and mobbing can help with this)

Dan wants to hear from you!

What ideas have you tried and seen work for getting code to \u2018done\u2019 within a sprint?

What have been some things you\u2019ve tried and haven\u2019t worked?

Would you be willing to start taking more notes throughout your day and then give yourself some time to reflect on those and identify your own areas of growth? And, if you do, what did you find out?

\xa0

Mentioned in this Episode:

The Scrum Guide

\u201cWagile\u201d (Waterfall-Agile)

Pair Programming

Mob Programming

Agile Coaches\u2019 Corner Ep. 45: \u201cThe Benefits of Mob Programming with Chris Lucian\u201d

\xa0

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!