Scenario: Your team is heading into a sprint planning meeting to determine what they will work on in the upcoming sprint. Everyone is happy, life is good until the multiple stakeholders show up with one line requirements wanting the work completed on Friday. Oh, and here’s how you need to implement the solution technically.
Reaction: The team goes through the five stages of grief (Denial, Anger, Bargaining, Depression, Acceptance). The work is still committed to, and the team is discovering half way through the sprint that each item is really an “epic” and not just a story. Now the team stresses out trying to rush to complete the committed work or the velocity will go down. In the meantime, 5 new bugs have popped up and an emergency requirement has just been added at the last second. Oh, one more thing, there was carry over work from the last sprint that was not accounted for. Moral goes down, stakeholders are not please, and the cycle continues again in the next sprint planning.
Welcome to a typical day in tech.
Antidote: There are a few things wrong that are going on here. Can you see them? Let’s look at this together.
- Too many stakeholders. – The team needs one voice to speak and ask for the work to be completed and prioritization.
- Requirements are too vague (duh). – You need to prep your stakeholder (singular) with backlog grooming work BEFORE the meeting occurs. I consider this practice before the sprint planning meeting. Prepping the stakeholder to deliver the information you want, in the format you want is key to a smooth sprint. (Don’t forget, you will still go over these items with the team together, this is just prep). * BTW, if you are not already, I strongly recommend using the Gherkin format for writing stories so they can be turned into functional tests later.
- Stories that are not ready should be rejected. – This is not new, but do you have the courage to stand up for your dev team and pushback? You might lose the battle, but ultimately winning the war by setting the correct expectation.
- Requirements are huge. – Break the stories down (duh). Anything larger than a “medium-sized” story should be broken down. Do this to give yourself a chance to succeed.
- Overcommitment. – If the story cannot come off for any reason, have the team commit to an investigation to deepen the requirements. This provides some movement on the work, and let’s the stakeholder know you are still not comfortable forecasting a solution or timeline. Or perhaps commit to “code complete” or some other partial status to let the stakeholder know that movement is occurring, but it will not be delivered completely by sprint end. Alot of times, things like testing, setting up an environment, releasing to prod, or even waiting on someone else is missed when making the commitment. Break these up and commit to them separately, by doing so, you are communicating better and setting expectation.
- Don’t fill up the cup completely. – If you were drinking coffee, would you fill the cup to the absolutely top before drinking? Of course not, that would immediately cause you problems when you tried to drink it. So why would you max out your capacity in a sprint? Think about it, you are always going to have interruptions, bugs, new requirements coming in the door (that why it’s called Agile). I like to tell the teams to budget for 60% capacity to leave some leeway for “sprint-busting” work.
- Not Tracking the velocity. – The team needs to see their “scorecard” against commitments so they can get get better and self-manage. make a point to make sure they are not feeling performance pressure of their velocity is slow. This is a tool to help everyone get better around planning, not to weed out the “non-performing” developers.
- The Dreaded Deadline – Stop these now. Really. The team should design the correct technical solution and how long it will take to complete. If the estimate is too long for the stakeholder, they can use tools like cutting scope, changing the date or sometimes adding resources (forgive me readers of “Mythical Man Month”). The technical team should always be offering alternatives and solutions that work.
- Stop telling us the solution – Often stakeholders are very comfortable providing direction, but in the wrong way. When you are confronted with someone that gives you the exact technical solution they want, you should stop right there. Your powerful tool is of course to ask questions. “What are you trying to accomplish?”, “Why do you need this?”, “What happens if we implement only this?”, “Does it have to have a the head of a shark and the body of a lion?”. Asking these questions allows you to take back control of the requirement and really drill down what the stakeholders need.
- Have Fun. – What? This is not in the Agile Manifesto! Nor is it in any of the methodologies. The explanation is simple. Software is built by people. People need recognition, challenges, and want to enjoy their career. People are what make companies. It’s not signs or logo, nor the colocations or Macbooks we tote around (sorry pc users). Having fun and not stressing about your job increases retention, but also creates a tighter team bond. You will accomplish more, have better quality software, and overall be a more successful with a lot of smiling friends around you.
Now that sounds pretty good, doesn’t it?