Agile Coaches' Corner Getting to ‘Done’ Within a Sprint
Today Dan Neumann will be focusing on the topic of getting to ‘done’ within a sprint.
Getting an increment to ‘done’ is really challenging — 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’re used to really long delivery cycles with long requirements, think about how fast a two-week sprint will go!
So how might we get to a done increment? Tune in to find out!
Key Takeaways
What does it mean to get ‘done’ in a sprint?
In the Scrum Guide, it says that the increment must be done and in usable condition
The team ultimately decides what ‘done’ is (but it does need to be in usable condition)
What do we not want to do to get to ‘done?’ What methods — though, often posed — simply do not work?
Nailing the requirements up-front so they’re moving because it’s 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: ‘What did the developers do for the last third of the sprint?’ And, ‘What do the quality specialists do for the first two-thirds of the sprint?’ etc.)
Implementing “Wagile” (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’t done (this is the best time to stop and have a retrospective)
Dan’s recommendations for new teams looking to get ‘done’ 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’s 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 — 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 ‘done’ within a sprint?
What have been some things you’ve tried and haven’t 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?
Mentioned in this Episode:
Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”
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!