(image from geograph.org.uk)

In one of my previous post titled You Might Not Be Agile If , I outlined some agile anti-patterns.  Recently, I come across couple of anti-patterns that make good fodder for discussion.  Both these patterns are something a Scrum Master should be able to avoid, corrrect.

Anti-Pattern: Only using partial team to size the backlog

The first one is where a team used only developers in sizing stories.  Well, is it any wonder then, that the team discovered itself in bind? Testing tasks turned out to be too large.  Surprised? The sprint committments got  jeopardized?  And is it suprising that team members ended up putting in extra hours to try and salvage the sprint?  In this particular instance, the reason was:  some team member felt the sprint planning sessions were getting too long.  So a select few team members pre-sized the backlog and tasked out the stories ahead of the planning meeting.
Now, there is a reason why we strive to construct cross-functional teams.  And we prefer using a consensus based estimation process such as planning poker.  We want to avoid, what some quant-driven companies have started calling –  HiPPOs hijacking and monopolizing the decision making process.  HiPPO stands for highly paid person’s opinion or alternatively, a highly positional person’s opinion. 
If a team lead, a Scrum Master, a Product Owner, a single team member, or a functional group “Hippos” the team, then that stunts the team from self-organizing.  You are back to command-and-control decision making structure and you miss out on the wisdom of the team – not very agile!  The planning poker or similar agile estimation process involves all team members, and it expects that all views and perspectives are allowed to be expressed, shared and discussed.  Two good things come out of the process, one is that you get a team members’ committment, not just compliance.  The other is that you get a much better and realistic view of your work, and you have intrinsically motivated agile team that owns the estimate and will do everything in its power to deliver on it.
But aren’t agile teams suppose to move fast?  Time-boxes are of course very important, but so is discipline.  If you don’t involved all team members, or if you short-change the consensus building process, you get uneven results.  What’s more involving the team allows it to gain tacit knowledge through meetings and conversations, which makes them better at getting things done.   
At the same time, agile teams are not deliberating, debating bodies.  They exist to produce great working software.  Reason given here was that the team wanted to have a shorter planning meeting.  So let’s talk about that.
The general rule of thumb that has worked for many teams is to allocate 1-2 hours per sprint week for the planning meeting.  Say you have a 3-week sprint, then normally your team should allocate anywhere from 4-6 hours of planning.  To make sprint planning go faster, there are few practices you can follow:
  • PO has already communicated her priority stories for the upcoming sprint during grooming sessions, which are taking place during off-planning weeks.  All prioritized stories are well understood and sized by all team members.
  • Most agile planning software allow you to copy a story.  So a good time saving practice is to create a “template” story which contained often encountered tasks.  The Scrum Master as part of his sprint planning session preparation can then copy this story, overlay the actual story card and the acceptance criteria.  This approach has another benefit too.  You can embed tasks associated with your story done criteria, which then serves as a good checklist for the team.  For example, if  your team forgets peer code review task on every story, then having an explicit task  as part of the template serves as a good reminder for the team to include for every story.
By the way, the team size matters too when it comes to having an efficient sprint planning meeting.  Having a goldilock-sized team of 7 (plus or minus 2), allows consensus building to occur without a huge time sink and makes for faster sprint planning.  I recall, a team that chose to go with 15 team members, their planning meetings used to drag out to almost two full days (14-16 hours) for a two week sprint!  How productive is that?!
Anit-Pattern # 2: Committing on more work than what can be delivered.
But is there maybe another deeper anti-pattern as a cause for this team that chose expediency over allocating “right” amount of time for sprint planning.  Could be that, they are trying to shove a whole lot more work than they can realistically take on during a sprint?.  (No time to waste, can’t you see, I have more code to shovel over to production, every day, so I will take any and all shortcuts possible, especially if I can avoid having uncomfortable conversation with my stakeholders!)
If that is really the issue, than there are good practices you can follow.  I have found that when doing capacity planning, it is better to start the team’s capacity at 80%.  So, if you have 14 working days (counting 1 sprint day towards demo, retrospective and planning meetings for a 3-week sprint), each team member will have , roughly, 90 working hours (14x8x0.8).  Using 80% capacity means that you do not have to account for tracking all the overhead minutiae such as company or team meetings, emails, water cooler chats, birthday celebrations, or just team members taking time to be helpful, or honing their own skills.  (An aside: this is also another reason, why I think it is a bad idea to use agile lifecycle management software for project time tracking.  It distracts from delivering good software and makes accountants out of team members).
Then, you subtract any “planned” PTO time.  Next comes any production support work that your team generally has to respond to.  The percentage varies from team to team.  Using a rolling 3 sprint average to even out the spikes as your starting point and adjusting according to your circumstances, works.  It is also a good practice to task out 1 or 2 more stories, over and above your team velocity.  So in case, you end up using less than your allocated production support capacity, you have a ready story to work on.
And finally, subtract any earmarks from your capacity.  For instance, many teams negotiate with their Product Owner and stakeholder, part of their capacity towards fixing defects, or doing test automation, or for code refactoring. 
If your team doesn’t account for all these things up front, you are probably operating on an illusion that you are going faster.  In reality, you are probably spending more and more time in remediating code and responding to production emergencies.  If you want to read more on this anti-pattern, check out Mark Lawler’s recent post called Sprint Planning Like It’s 1999
You say,  if I do all these things, there is no way, we are going to converge towards our project goals?  Maybe.  But, equipped with data, you may have a difficult, but an honest conversation with your stakeholders.  Should quality and delighting customers be sacrificed to meet the deadline, or should other creative solutions be explored?  Should we invest some time in building good software, or should we pay a whole lot more later?