Dan Barber, from the Customery Crew, wanted to know what it would be like inside some of Neil’s scrum events. In Scrum Dynamics 26, Neil walks Dan through one of his recent ten-day sprints day-by-day from sprint planning on Monday morning to the sprint review two weeks later. Here’s how it went…
Day One. Sprint planning is at 3pm for two hours on Monday afternoon. We finalise the sprint goal, determine and determine the sprint backlog. On Tuesday morning, we start work on any stories carried over from the previous sprint, one-point stories and spikes. The Dynamics 365 squads hold their daily scrums at 9.15am and 9.30am. On Tuesday morning there’s a showcase for our business stakeholders. Tuesday afternoon is our retrospective for the previous sprint.
Day Two. We have a technical design session on Wednesday morning to finalise the technical designs for the more complex stories. In the afternoon the analysts run a storytime workshop to elaborate and estimate stories for a future sprint.
Day Three. The first product owner review session is on Thursday afternoon. It’s an opportunity for the tester to demonstrate any completed features for the product owner’s acceptance (fingers crossed).
Day Four. Applause in Friday’s daily scrum as the first few accepted stories are moved to done. We sometimes hold back on completing all the definition of done activities until the end of the sprint so that developers can get working on another story and let the testers start testing as early as possible.
Day Five. Monday doesn’t have any scrum events so it’s a solid development day. I’d love to say we’re halfway through the sprint backlog when we’re halfway through the sprint, but we’re often still playing catch up.
Day Six. On Tuesday morning, some of the developers have finished all the stories they forecast they would complete. They help other developers complete their stories, work on spikes, chores and bugs. We can bring stories in from the product backlog, but only if the development team agrees that we can get the story developed and tested before the end of the sprint.
Day Seven. Our aim is to be dev complete on all story cards by the end of the day on Wednesday so that our testers have sufficient time to test all our stories and have them accepted by the end of the sprint.
Day Eight. We’re helping the testers by responding to feedback. We don’t track bugs reported by the testers or product owner. Instead, we just fix them on the spot. Unless they are low priority and we don’t want to fix them in this sprint, or they were reported by someone outside the scrum team. If there aren’t any bugs, then we’re finishing definition of done activities and working on spikes and chores. We’re helping our devops engineer automate all our deployment tasks. We don’t want to have any manual deployment steps. So we automate everything using Atlassian Bamboo and Octopus Deploy. We also have another storytime workshop to elaborate and esitmate stories for a future sprint on Thursday afternoon.
Day Nine. Thank goodness it’s Friday. There aren’t any sprint events today. We might run an ad-hoc design workshop on Friday morning to take a look at any complex epics in the backlog and figure out what we might need to do with them. We have a quick, 30-minute meeting to plan Monday’s sprint review: what are we going to demonstrate, and who’s going to do the demo? Our developments rotate this responsibility so that everyone gets a turn.
Day Ten. It’s Monday morning and never as calm and relaxed as we’d like as we rush to finish any last-minute stories and get them accepted. Sprint review is a 1pm and an opportunity for all the work streams in the program to come together. We recap our sprint goal, describe the stories we got done, and highlight the stories we didn’t get done. Then we demonstrate some of the done stories. We get some good technical questions from the audience. Phew. Time to take a short, unpaid vacation before sprint planning starts at 3 o’clock.
The cadence of my other recent Dynamics 365 scrum teams has been similar. We all have the give events of scrum, and we’ve added in storytime, technical design workshops and the product owner review.
How does your sprint cadence differ? What other technical practices and workshops have you found it useful to add to your sprints? Let me know in the comments below.