Agile, Planning, Scrum

On My Phobia Of Sprint Planning

No Comments

Yes. You heard it here first. Sprint Planning sessions fill me with fear.

Like most Scrum Masters, I’ve attended many Sprint Planning sessions – for many different projects, for many different teams. The ones in which there’s a distinct client (rather than for a product owned by the business) strike a particularly strong sense of foreboding into my soul. What if I don’t understand the requirements? What if the client gives me a hard time and I have to think on my feet? What if I can’t contain the developers’ enthusiasm to underestimate everything to keep the client happy? What if I can’t contain the developers’ enthusiasm to wildly overestimate in order to protect themselves? What if I go over time and we’re not finished? What if, what if, what if???

And then I take a deep breath, turn the door handle and step, once more, unto the breach..

The fear

Of course, if all Sprint Planning sessions turned out to be as bad as I feared, then I would have quit Scrum Mastery a while ago. Maybe I would’ve taken up something like shark painting or oil rig wrestling.

The first mistake I make is to be fearful for myself. Two things then come to mind, and provide immediate comfort:

  1. if I’m scared, how do I think the team must feel?
  2. it’s a team effort and the developers know more than I do; draw upon them for support and give them yours

By now, my heart rate has dropped a little. Then more lifelines get thrown down to me by my reasoning:

  1. being brave is about being honest. The outcomes are better following an honest appraisal of a problem than from following one given under duress
  2. the last iteration is behind us, we’re closer to the finish, and there are new discoveries ahead. Rejoice!

Facing it

As with checking in during retrospectives, I combat my fears by trying to be the first person to speak when the meeting kicks off. I state the intended outcomes of the session, the duration and all that administrative stuff, and I make it clear that the meeting is about discovering work and focusing on creative ways of addressing the Product Owner’s goals. By making this first stab, I’m quickly able to bury my nerves and get on with it.


Image courtesy of Frederick Homes for Sale, Flickr (CC)

But some Sprint Planning meets can be…. difficult. So what happens when my nightmares start to come true?

I’ve been on the brink of an argument with a client during one memorable session. But rather than let emotions get involved, I reminded myself that lives were not at stake here; just assumptions – some valid, some not. I assured the client that I was only labouring a point because I felt I had evidence to back up my claims (about estimation, now you ask) but that we, as a Scrum team, were there to not only validate his assumptions, but to challenge them and present hopefully better alternatives. After all, we’re paid to think, not just do.

Keeping your head and your cool is key.

Sometimes the problems are closer to home. Like the time the team I was serving never finished any stories, and each planning session was a repeat of the previous; always choosing the same not-yet-Done stories. In those cases, your skills as a Scrum Master are tested quite hard. You have to come up with a way of breaking the deadlock, lifting spirits and ensuring all parties, stakeholders and Product Owner included, know the facts, no matter how painful they are to admit. You need to extract valid points of learning from failures such as these. And, of course, you need to establish a way of not going down that alley again in the future.

So, with all this going on, it’s no wonder I get a little shaky! But, that all said and done, a little adrenalin can certainly add gusto to your mastery.

Agile, Planning, Scrum

On My Love-Hate Relationship With Tools


I don’t hide the fact that, given the choice, I’d rather have my feet swapped out for frying pans, than have to use Agile “management” tools. I make it clear to the teams I serve that nothing really beats what we’re finely tuned to be good at: face to face encounters. I keep away from software tools when it comes to working within the Scrum framework.

This resentment began, I think, when I was introduced to Jira. (My recall is foggy because my brain has put a lot of effort into erasing that moment.)

I was in the throes of becoming a Scrum Master, and was feeling particularly excited about the prospect of using big whiteboards and PostIt notes and marker pens and magnets. In fact, I may already have started using them. I’m not sure.The company I was employed by was rolling out Jira as a means of not only tracking defects but, God forbid, sprints.

No matter how hard I tried, at least one team refused to move to a physical board. It was a team of three, and they sat next to each other no more than 1m apart. Yet they insisted on using Jira to keep themselves updated. And just half a metre from them was a shiny new whiteboard on wheels, ready to be drafted into action at the drop of a hat. I’ve no doubt they probably used Google Talk to chat to each other too.

“Individuals and interactions over processes and tools.”

Tool usage in itself may not be a problem, but the tools themselves restrict us. For example, in the same company, the Product Owner wanted to see how the team was doing with her stories. For the aforementioned renegades, we had to arrange a Jira login ID (but we’d run out of users so had to boot someone off to make room for her) and then train her in how to use the tool. I’m not convinced we’d bought into Scrum’s “information radiator” ethics. Information coolers, more like.

But the issues aren’t just around visibility. I’ve used other Scrum tools that absolutely insist upon the users entering estimates against stories. But if you’re working with a team that has moved beyond estimation, the tool becomes unusable. The workaround? Type in any number against the estimate. This is fine for the developers, but I had one case where the stakeholders also had access to the same software and they raised concerns about the velocity of the team. The software told them that the team was going to be late on delivery based on the numbers they’d punched in. I’ll repeat that. The software told them. Not the team. Not the Scrum Master. But some software.


Physical boards give you the freedom to modify your way of working without waiting for a change request to go through to a team of open source developers spread across the globe. For example, I’ve recently been using Taiga. It’s a great looking bit of software and really easy to use. But hold on, what happens when you want to close a sprint? Well, normally, you’d make a note of the stories that didn’t reach Done, maybe note also the ratio of stories Done vs not Done, and close the sprint. But Taiga operates on the policy that a sprint closes when all the stories are Done. Until then, the sprint can’t be closed. OK, so I’d love my teams to get all their stories to Done. But in reality, this doesn’t always happen In fact, Scrum works on priorities, so sometimes you half expect the stories near the bottom of the sprint to not get finished. C’est la vie. Taiga, instead, operates on the fallacy that teams will get all their stories to Done. Always. The solution? At the end of the sprint, you have to move all off the not-Done stories out of the sprint and back into the backlog. The sprint then closes. Oh, but now the tool will tell you that you completed 100% of your stories in that sprint, which was zero. Gah!


Recently, I’ve found myself acting as Scrum Master for a team that’s located about 200 miles from me. I’m using agile management tools. It makes me feel a little dirty, but the team is getting some use from them. We were using Taiga (see above) with some manual note taking thrown in to cater for its restrictions. I can live with that for a while. But what about retrospectives? This is an area that I really enjoying indulging in. But that’s when I’m in the same room as the team, reading emotions, watching body language and, in many cases, veering wildly off course to cater for something crazy that pops up during the exercise. With a team that’s 200 miles away, I had to revert to tool usage again. I scoured the web for a cloud-based retrospective tool. I found some. I tried one for two retrospectives. It worked. But boy, by the end of each retrospective I was exhausted! Why? Because I had imagine the feeling of the remote room; I had to work hard to listen over VoIP to gauge the sentiment of the team. It was very very hard work. The tool allowed us to type things within certain columns (like Mad, Sad, Glad) but what was missing was that human touch. The unsaid.

I don’t blame the tool for this; it was making a good job of a less than desirable situation. But boy would I have preferred to be there, in the thick of it.

So, I’m no tool playa. I’m a hata. Word.

Agile, Life, Planning

Life Feels Better When You Have a Plan

No Comments

On my walk to work each morning, I pass a bus stop sporting an advertising hoarding for Scottish Widows’ life assurance products. (The Scottish Widows mascot is such a young widow, poor woman.)
Their strap-line for this current campaign is, “Life feels better when you have a plan.” And on their website, they talk about how having a plan makes life feel “lighter.”

What caught me about this new campaign is its truth; life does feel better when you have a plan. But I suspect that, in an effort to sell more life assurance policies, the campaign managers were hoping readers would interpret this as “Life is better when you have a plan” and therefore, “Life sucks unless you have a plan” and onto the conclusion, “Life follows a plan. Buy yours now. Rest assured.”

Plan To Be Happy, Don’t Be Happy To Plan

When you see detailed plans in software development projects, you can tell that a certain group of people draw great comfort from them. They provide the illusion that a chain of events will happen, culminating in the plan’s ultimate delivery or conclusion. And when these plans are printed large and bold on a massive wall, their impressiveness is hard to resist. They look awesome!

If you’re an Agility fanboy (or girl) like me, and specifically if you’re a Scrum Master, you’ve probably preached to developers and Product Owners and Stakeholders about the need to not have a plan. Or rather, you probably educate them about how plans change and how by not having a firm plan is actually an enabler and permitter of change. It also breeds the ability to cope with change. After all, how many agile projects do you know of that use a Gantt chart to work out what’s happening deep into the future?

Death and Taxes

Life’s two certainties, according to Benjamin Franklin. I’ll add a third: uncertainty. Nature has no plan and has little respect for yours. Making a plan for life is fruitless.

OK, harsh and depressing words admittedly,  but allow me to provide some solace. The journey you embark upon while trying to realise your life plan is likely to be more fruitful than the plan’s conclusion. In fact, I’ll bet it’ll always be more fruitful. This is because life and Nature throw things at you which you never expect, and it’s by coping with those changes, those curveballs, those monumental cock-ups, that can force you to change direction, make a new plan, invest in coping strategies (in case the same thing happens again), run away and hide until you think of a way to deal with it, and the rest. And it’s highly likely that after you’ve made these adjustments, you’ll feel happier or, to quote the aforementioned ad campaign, “better.”

And so it is in software development. And music production. And bathroom installations.

I’ll end with these words from humanistic psychologist, Carl Rogers

The good life is a process, not a state of being. It is a direction not a destination.