Timeline of a 2-week Sprint

Timeline of a 2-week Sprint

#26. 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 st

Support the show (https://buymeacoffee.com/amazingapps)