We decided to make the planning a lightweight process, and started committing in the worst possible way – by our gut feeling My stance was: let’s start with something simple and basic and we’ll adapt on the way. We didn’t formally break down stories into tasks, and that wasn’t a problem. We only started doing that around sprint 8 or 9. We concluded that breaking down stories into tasks makes sense for some stories, but not for other really simple ones. My task on the other hand, is to ask the team weather they want to do the formal breakdown or not, thus making the decision explicit.
Our planning meetings last from one to three hours. Sometimes, refinement sneaks in into planning. A smell, we will all agree. Theory says that it’s a good practice to temporally separate the activities of refinement, various scope discussions, and estimations from actual commitment. We have talked about that in the team, they understand the dynamics and generally agree with me but we, like many other teams I’ve coached, haven’t really started to live that principle straight away. On reviews, we sometimes hear really interesting feedback related to newly shipped features, and the team wants to pull it into a sprint straight away. We sometimes even do it, but we always consider the risk we’re taking, and discuss about it with the Product Owner. Despite everything, the story still has to fight its way to the top of the backlog. Sometimes developers really have a burning desire to take that small feature update into the sprint and in that moment I’m not standing in the way no matter the process. It’s very human to get something Done when you’re in the middle of it. Science has even given that phenomenon a name – Ziegarnik effect – e.g. waiters have better recollection of still unpaid orders. Still, I remind the team of our Definition of Ready and gently remind the team if I have reason to believe they’ve missed something.
Planifinement.
It was the planning of our third or fourth sprint. We started as we usually do, by pulling stories from top of the backlog. After taking some 15-20 minutes to get back into the stories and the discussions we had around them, the team started a new discussion about one particular story – one that was already refined (or so we thought). A new refinement session started. Back and forth with the discussion, almost as if we haven’t had the original one. It took more than an hour, and the main thing I remember is how I felt. I’ll be honest and admit – I was furious. I know it’s not a word from a professional business vocabulary but it’s the best one that describes my situation . What I was thinking the whole time was: “Damn, how come you (developers) didn’t see that you don’t understand each other during the original discussion? You’re together for two months already! How come you didn’t see that the story is a Gordian Knot, and why didn’t you handle it with extra care?”. Someone familiar with facilitation surely knows the dynamics – when people just go their way. But no matter how much angry I was with them, no matter how slow and sometimes non-existing the progress seemed, it was still there. So I hanged on that thread, managed to keep my calm, the team did their refinement, and they did come to a common understanding. Timebox was completely blown, the team exhausted, task breakdown didn’t happen but the sprint was successfully finished and the users we’re satisfied.
So, what do you do?
The situation clearly shows what happens when refinement isn’t done well. The only cure against such planirefinements is being proactive by respecting Definition of Ready. The team, and now I’m talking in general, won’t want to (and shouldn’t really) pull something that isn’t clear into sprint. Planning is often viewed as the last chance to clear (or refine) things up – which is wrong. Being proactive is key to the whole situation, and every Scrum team member is responsible for it. Not just PO or SM or any particular team member.
Sometimes it takes a bit more to load the refinement discussions in our brains so commitment – Planning One – takes up to an hour. Other times we’re done in 15 minutes. Is that a problem? I don’t think it is. If the team wants to spend more time recalling what they’ve discussed beforehand – let them. If they don’t – no one should make them. Our velocity rose up to some 5 stories per sprint, on average. When we’re all in the office – no one is on vacation, sick leave or taking college exams – we pull up to 6-7 stories, and sometimes we’re down to only 3. We had one sprint in which two members went on a 5 day course, and one or two sprints where one members was taking exams.
How much story points is that, you ask?
I’ll answer with a counter question – does it matter? And to whom?
To us, it doesn’t matter. In yesterday’s weather we only use the number of stories, but even that is not an information of particular use. People are spending so much time together that they already know how much they can get Done, and they prove it with their delivery. I see a tremendous amount of agreement around how much fits into a sprint, and that’s fantastic. Our management also doesn’t see the value of using story points as a success metric. They know very well that that particular metric can be gamed and that we’re not in the business of delivering more story points. We’re in the business of delivering software that makes our users happy, and makes them want to use our software even more.
Next up – review! Stay tuned…
