S2:E4 - Sprint Planning of the Agile Wedding
Hope you all are enjoying your weekend.?
I am extremely sorry to keep you waiting for so long for S2:E4. Without further ado, Let’s quickly recap what we have covered in our?Series of Agile Wedding?so far:
Moving forward, in this article I’ll cover how we did Sprint Planning for Pratiksha & Rohan’s Agile Wedding.
Recall our Series 2 - Episode 3, where we divided the user stories written by Pratiksha & Rohan?(Product Owners)?into two Sprint Backlogs -?Sprint 1: Engagement?and?Sprint 2: Marriage.?Each of them had been aligned for a Sprint Cycle of 2 weeks.?
The next day, for the Sprint planning, everyone?(with their assigned roles & responsibilities)?was pumped up to take up the tasks and work on them in an agile way.?
For one of the User stories related to 'Venue Finalization', we needed the?guest list to do the hotel bookings and the other necessary arrangements.
…the team had few reservations on taking the story into the sprint as no one was sure about the number of guests expected for the marriage ceremony amidst COVID-19. And there were a lot of unknowns and dependencies in terms of the other wedding arrangements.?
Well, be it professional front or personal, the requirements must be sufficiently well described/understood and needs to be free from any external dependencies & unknowns.?
In Agile-Scrum, A Definition of Ready (DoR) enables an Agile Team to specify certain pre-conditions that must be fulfilled before a story is allowed into an iteration/sprint. The goal of DoR is to prevent problems before they have a chance to start. DoR is a checklist of what needs to be done to a product backlog item before the team can start implementing it in the next sprint. It is the Product Owner’s responsibility to tick all the boxes of the DoR before he/she should ask the Dev team to accept the story into the Sprint.?
So, based on the discussions, opinions, and concerns raised, Amit - the scrum master with the mutual consent of all, divided the user story?“Venue Finalization”?into two parts and added them into their respective sprint backlogs.
And ultimately, it turned out to be a sensible decision!?Qualitatively focusing on the shorter & outcome-based sprint planning’s, breaking larger user stories into small chunks, and accomplishing the underlined tasks in the stipulated time i.e. the sprint cycle is an Agile Ways of Workings.?
Agile-Scrum Teams (along their agile-maturity journey) master the art of knowing when they have reached the point of a plan that is “good enough”. They understand the fact that over-planning leads to tunnel vision that prevents them from seeing other more valuable opportunities along the way. Or, even worse, over-planning pushes us to stubbornly rely on a plan that is no longer useful and will lead us directly to failure.?
Coming back to the story, what happened next was super-duper fun.
The family members had to estimate the user stories and for this,?we all played the Planning Poker game.?Honestly, it took me to our Sprint Planning ceremony at the work front where team members come up with varied estimates based on their understanding of the work and Scrum Master had to facilitate the conversation to reach a consensus.?
A similar situation happened over here too!
And, I had to assist Amit our Scrum Master to facilitate the discussion (conflicts :) ) to reach the consensus while taking?complexity, risk, and uncertainty into consideration.?
领英推荐
In Agile, Estimation is a team sport.?
Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface. Likewise, design changes require not only the design team's input but that of development and QA as well.?
Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.
Agile teams, therefore, don’t fall victim to estimates being made in a vacuum and very well understand the fact that not involving everyone is a fast track to failure!?
Let’s go back to our story!
After finalizing the complete sprint backlog of Engagement with user stories, estimation, acceptance criteria, the definition of done (DoD), tasks, etc.,?we tried to put all these stories on the board. And a provision to move them as work progresses from?To-Do?to?In Progress to Done.?In the same way, we set up Kanban Board to help visualize work, limit work-in-progress, and maximize efficiency (or flow) in Scrum Teams.?
We finally started the sprint with the Sprint goals outlining the objective of the sprint and letting everyone in the team know what should be accomplished during the sprint
The very next day, came the part of the Daily Stand-Up Ceremony wherein I briefed the Team about some important aspects of this ceremony like?
1.??What tasks had been carried out?yesterday?
2.??What is?today?in the task bucket?
3. How?it would be done??(Optional)
4.??What are the?roadblocks?
Further, I explained the dos and don’ts of the daily stand-up.?
Folks, the first two days of the stand-up were super smooth, and everything went as per the sprint planning. But on the third day, we came across impediments that made Pratiksha & Rohan upset.
You will have to wait :) to know what happened and how the team managed to tackle the situation.?
Stay tuned and enjoy your weekend to the fullest. :)