Teams new to Scrum have a product backlog. The backlog will be groomed to some degree, typically have clarity for up to one to two sprints. The priority will be clear, with fair amount of detail on the requirements. The estimates may be present, it could be story points or a masked form of an effort estimate.
The Product Owner (PO), who is not co-located in most of the teams will participate in Sprint Planning and along with the Scrum Master and team pick a set of stories to be done in the Sprint. After this the team jumps into doing the work. Detailed Sprint Planning is given a miss as PO will not be available for the entire duration and the team reluctant to do task based estimate for variety of reasons, if they do it is done by a few senior members of the team.
This is where the first intervention from coach is needed, coax them to do detailed planning i.e., break down the stories into tasks and corresponding effort estimates. Insist that the entire team be involved and ensure that they balance the work they are taking up with the capacity the team has. Here is where they get to see one of the characteristics of Scrum – uncovering the problems at the earliest, and as a coach one should ensure that they become aware of it.
Few things they discover:
– there may not be enough Analysis/Dev/DBA/QA capacity in the team
– some of the team may not be fully utilized
– as they break down stories to tasks they realize that some stories cannot be completed, due to external dependencies, that is unlikely to be fulfilled.
– they may require more information from the PO.
– lastly the entire team gains an understanding what is planned to be accomplished.
And it is interesting to see how they work around this:
– make use of team members not fully utilized to accomplish some of the tasks.
– the above at times involves redistributing the work, so that team members volunteering outside their domain, can take up relatively simpler tasks.
– go back to PO/stakeholders and try to get the dependencies resolved or pick another story, this one requires a push from coach.
– get clarity on requirements from PO, this has to happen the next day.
– re-adjust the sprint backlog taking the above into account.
At times guidelines are adhered to, planning sessions is time-boxed, they assume that all planning needs to happen in one sitting. Here is where, as a coach, one has to make them see the “why” behind a particular step, “what” outcome is desired? The outcome of having a proper Sprint Plan is more important than accomplishing it a single time-boxed session.
As they complete this they realize that in past sprints, they grappled with these issues, towards the end of the sprint. Now they have ample time to cope with it – the benefit of Scrum uncovering problems earlier is leveraged.
There is reluctance to do task effort estimates. In the traditional planning task estimates are done for entire project even with some requirements not being clear. This would have resulted in lot of waste, this coupled with notion that agile means no planning is the major cause of the reluctance. As a coach, one needs to highlight that there is better clarity on requirements and it is being done for just a sprint, so there is no waste. The reluctance is also due to lack of understanding of the difference between story point, size and effort estimates, this needs to be addressed.
At this juncture the team is ready to make and take on the commitment with higher confidence. You can see the related blog on retrospectives.
