In the first few sprints I was the Scrum process guardian. I sent out invitations and did necessary preparations, facilitated the meetings and gave out nuggets of knowledge to people when the situation demanded. The main challenge for me was not to overload the people with theoretical knowledge. Since I didn’t do a 2 day Scrum education and a separate kickoff like I do with clients, there were tons of explaining to be done, and it wasn’t so easy. Occasionally, I caught myself going to broad – “Hey, there’s no room for practical application of the concept you want to explain”. Then I remembered my professors from college and the phenomenon where each professor likes his classes more than anyone else, but also the fact that many students don’t share their opinion.
Scrum process has had good and bad days in my team. I will do every Scrum meeting in a separate post, and in this one I will do – you’ve already guessed it
Refinement
In the first two sprints it was one meeting per sprint, ranging in duration from one to two hours. The first annoyance was that we had it in the second of our two week sprint – just two days before the review. That was too late and caused some refinement at planning time, planning slipped tasks weren’t being broken down, and the decisions were more on the ad-hoc side than well-thought-through. Then we moved it to the end of our first week, and afterwards decided that we would have two meetings per sprint. During the first we tried to get our stories as close to Ready as possible. Outstanding questions we’re pinned down and had to be addressed until the second refinement. There we shared what we discovered with others, and ensured that we were all on the same page. At first we agreed on time slots for the meetings and then sent out invitations few days in advance, but then – somewhere around sprint 9 or 10 – we were doing that completely face to face without any formal arrangements. Now when we need to prepare the stories the teams just gathers ‘round and does the work.
Around some stories there are mostly one-to-one conversations, around others there are full-group-with-PO conversations. We already got used to the fact that some stories are more risky than others, and have already tuned our radars to detect them – so we start refining them as soon as possible.
The meeting has evolved quite a lot in 13 sprints now, to the point where it cannot even be called a meeting – if I really had to call it some way I would pick “people and subject matter diverge-converge workshop”. What remained though, was the fact that we had (and still have – a refined version) a Definition of Done, and no work can go into a sprint if it’s not Ready. I insisted on that constraint from the start, and yes, it wasn’t smooth sailing all along. There were times where the team didn’t prepare the stories well enough and our planning meetings went south – up to a few hours without the task breakdown. There were moments where developers thought they understood each other, but when they sketched their solutions (application screens) the opposite became evident.
Realizing the fact that you’re not in agreement with someone takes time. Sometimes you don’t have the time to explain everything, sometimes you just lack the energy, sometimes you’re just having a bad day, and sometimes prof. Wiio is in the room and every attempt to communicate fails. What majority of people don’t know is that we sometimes lie to ourselves – and on top of that we convince ourselves that others understood us. Sometimes people just don’t want to say “no, you don’t understand” to others and just want to put stuff under the rug.
It is my concern to observe, detect and expose such situations to my fellow team members, with – of course – a human touch and in a respectful way.
The story of message grouping.
Once we prepared a story that was about a more user friendly display of individual chat messages. If messages were sent by one individual, then the application would group them visually in order for a user to more quickly grasp who said what. It was all about one particular screen and it was the sole focus of the discussion. We talked about it two times (in a period of a couple of days), once on a “at a glance” level, and once on a deep level. The third time, when we wanted to make an estimate and close the refinement for that story, we did a “Sketch you own Solution” exercise. Surprisingly enough the team ended up with different drawings and understandings.
So what do you do in a situation like that?
I recognized immediately that the story is on a simple side, and that team members could fly by it without enough attention – after all it was just about message grouping – not challenging at all. So I tracked the conversation and suspected that common understanding wasn’t really on the level. I asked people if they would like to sketch their own visions of screens. They said “yes” and then presented them. The sketches had been visibly different in some aspects, sure enough. Despite that, the human factor in the team members concluded that they’re the same – to which I decided to stand up a little. I pointed out the details which were different really quick, and then decided to just stand back.
Why you ask?
Because there’s a thin line between proving a point and being downright irritant and provoking. Sometimes it’s just two or three words. Okay, back to start – so how do you make them understand? Those of you that work with people already know the answer – you can’t. The team has to develop a sense of understanding (or non-understanding) by themselves, and decide how deep they’re going to immerse themselves into details before they all say “we agree!”. Sometimes they can live with a little misunderstanding because they’re going to discuss and confirm it at development time. Sometimes on the other hand, the story is critical and will be viewed through a microscope by everyone, during refinement. Every story will be different, and how the team handles them is their thing – internal, completely owned by them and no one else’s concern weather I (or anyone else for that matter) like it or not. After all, respect is a core Scrum value – respect you team members and how they refine their stories.
After the discussion the screen layout has been agreed upon, story was pulled into sprint and things went smoothly all the way to the end.
I could give a few more examples of how individual stories were refined, but I want to drive the point home. Through our 13 sprints we proved to ourselves that one Refinement meeting per sprint was just a starting point – nothing more than that. That’s just what the creators of Scrum – Jeff and Ken – are saying. It’s an activity done throughout the sprint in a way that the team finds effective.
Next post – planning! Stay tuned…
