Why Project Managers CAN evolve into ScrumMasters!

Yep we know.

The Project Manager does not exist in the Scrum framework.

Does that mean, the traditional Project Manager cannot evolve into a ScrumMaster?

Hell no.

I’ve heard allot of ScrumMasters give it the “PM’s who become SM’s are doomed to failure, they just don’t get it ” …blah, blah, blah.

That’s crap.

It’s stereotypical, it’s ignorant and quite frankly it’s based on a very weak rationale.

Here’s why.

Project Mangers aren’t all dressed in studded leather cat suits cracking the whip.


There ARE awesome Project Managers who are more like Project FACILITATORS!

Facilitators, think humans, think leaders, think servant-leaders.


Management has styles!

Yes I know ‘management is a dirty word in Scrum – but your style of management can be a command and controller (no thanks) or the servant-leader (yes please).

Some PMs really are or show great servant leadership qualities.

They create purpose through explaining why the business needs what it needs, they don’t talk down to the team (treat ’em like peers not like a boss),  they facilitate, motivate, help create an environment conducive to effectiveness (Krispy Kremes help) – you know, all of that good stuff to create self-motivated, self-managing, high energy teams who want to bring value!

Ok so if you’re a servant leader is that enough?

Well, you need to know the empirical bit as well!

So PM’s getting involved in a software related project need to understand the basics of how we use an empirical approach to projects as opposed to a predictive one.

To touch on empiricism, it means (in the context of software projects) – there is usually allot more that we dont know, than what we do know. So, we deal with this level of uncertainty by working in time-boxs (sprints anyone?) & mitigate risk and anything that changes through the events and the rich interaction piece laid down in Scrum (stand ups, constant team huddles etc)

All I’m trying to express is the PM would need to get their head around how forecasting works in a Scrum team, why software isn’t like building a bridge and how to utilise team events to manage the inevitable change in requirements and estimates.

So all in all.

PM’s who are servant leaders that can understand the empirical process control theory – CAN become awesome ScrumMasters.

Right so on that note, I’ll be ordering an old PM colleague a copy of  The Mythical Man Month (empirical bit sorted) and a new personality (thats the management piece nailed as well) for christmas.


It takes two to Tango : Why the WHOLE Scrum team needs to OWN backlog refinement

The sprint planning meeting kicks off.

The story cards are put down, the PO starts presenting.

We get a high level overview from Product.

“Why do we need to do that story, how does fit in with the overall goal of the product”. A healthy, regular, dev question.

Product answered.

A debate began.

Different members of the Scrum team chipping in (me included) asking questions: “Why”, “how come”, “what’s the point”, “wheres the value init”, “isn’t it better to approach that problem this way”.

All of these questions pointed to a team wanting to understand the goal, the value behind each story card.

Nothing wrong with that.

Everything right with it I think.

I sensed frustration from around the room, the ” why so much questioning” tone was coming out from Product. You know the “we’re product and know what we want, can we just do it”.

Developers coming back with the ” we ain’t code monkeys and so we need to know the value behind what we do” tone. (Pretty chunky tone huh?)

I came out of the meeting with a sore head and had the following feedback from the Scrum team:

  • “Why are the Sprint planning meetings taking so long?” (Product & Development)
  • “How comes Product are not getting us the stories over in our previous sprint so we can see what’s coming up?” (Development)
  • “Why are developers asking to change my story? ” (Product)
  • “Why are Product being so arsey about us asking questions on why we’re doing this work?” (Development)

My response to all of the above (in order) began with these points:

  • Sprint planning meetings for a 2 week sprint take 4 hours (Cohn, Sutherland advise that we take the length of the Sprint & multiple it by 2-  a 4 week sprint planning can take up to 8 hours) This aint a hard and fast rule, but that’s the starting point for new Scrum teams – especially.
  • The Scrum team need to create an agreed schedule of when they will sit down and look at the next up coming stories for the next sprint – this allows the developers to familiarise & understand the value of stories earlier
  • User stories should be written by everyone, first we need to accept that point as that is part of Scrum – next, if a story can be written in a better way (using the INVEST rule) then we need to do what is best for the story
  • Product provides the  goal & must be willing to entertain questions on the value behind those goals – if we do not understand the goals, we may as well employ cyborgs who do not care for intrinsic motivation

So we have accepted that the length of a Sprint planning meeting can be dependent on:

  • The amount of preparation work completed in the Sprint backlog refinement sessions
  • The length of your Sprint
  • How long your Scrum team has been one team (maturity)
  • There are other factors which I won’t go into for now

I want to focus on the Backlog Refinement Schedule

There was a schedule but I questioned the regularity & the level of quality coming out of these sessions.

So to address the challenges of regularity & the quality of information, here’s the backlog refinement schedule & the expected outputs from each refinement session:

Backlog refinement Schedule


* “We are here” is like you being  at day 1 of your new Sprint 1.0

* The “Refine backlog” is for Sprint 1.1

* I have broken the Backlog refinement over 4 different sessions

* The output of each session should have an increase level of detail, for example by session two we should be 40-50 % complete on the Acceptance criteria (this is not a hard and fast rule, it’s an acid test to see what works)

* “LOCK DOWN” is when after 2 refinement sessions, we stop new stories from coming in

So the next time we walk into a Sprint Planning meeting we will find ourselves in a more informed position, where we as a Scrum team will collectively know the value behind most of the goals for the user stories with 50% of acceptance criteria complete & then we can focus on the tasking of work.

I just feel that a healthy Sprint Planning meeting would have had most questions on the user stories value answered in the refinement sessions – not the Sprint Planning meeting.

But that is not to say that conversation and questions will cease & that new questions on value within the Sprint Planning meeting will stop!

Colour me bad Mofo.

Colour me.

Colour me bad.

Yeah you heard me.

It’s your big old white board talking.

I see you shoving your planned and unplanned work on the same color cards.

But what the hell for?

Why aint you distinguishing between whats planned and unplanned VISUALLY?

I can’t show the world the reality of our 2 week time box if every piece of work is on the same color card.

When I say reality I’m talking about us as a Scrum team.

We’re meant to be focused on the sprint goal right?  BUT we do accept that we should have a small amount of  our team providing a support function – by small amount I’m talking 20%, but when the split is like 60% support  & 40% project work, that stinks of a serious problem.

Before you pipe up with ” but in Scrum unplanned work should never come into our sprints”.

Stop preaching to the converted buddy.

Arsene Wenger should be buying more players for Arsenal but we aint gonna change that sh*t over night sweet heart.

So what we need to do is be useful with our thinking.

Useful in how we can begin to deal with unplanned work. Of course, the ideal is to be hard nosed about it and just stop it from coming in- but not many of us would last long in our jobs as SM’s if we were simply dogmatic about unplanned work.

Useful thinking….to me?

I see it as ‘useful’ to find a visually powerful & undeniable way to  highlight the problems impacting the sprint.

If we can effectively highlight the problem we have more of a chance of getting the attention of the ‘right’ people to eventually fix the problem as opposed to the constant battling between PO & SM for when an unplanned issue flies in.

So how do we address the underlying problem of unplanned work – where can we start?

Grab your wallet and get over to Rymans.

Get some white cards, blue cards & red cards.

Say white cards are planned work & blue cards are unplanned work and red, they can be defects. (Don’t try and get clever thinking “but defects are unplanned work” – they are but I can’t be bothered to explain that right now, so read on).

Now look at this board, it’s the outcome of a Sprint:


We got 9 unplanned cards (blue)

We got 9 planned cards, y’know user stories (white)

We got 3 red cards (defects)

And we got 3 green cards (Spikes) (go back to Rymans, I forgot about these at the top)


When we present the Show & Tell to the business and show that 50% of our work is project & 50% is support work -> that sends out a powerful message.

We just want to present the facts.

Maybe,  that’ll encourage the business to:

  • Disturb us less with unplanned queries
  • Inspire Product Owners to chase down whoever they need to chase earlier to get work into the sprint planning meeting
  • Justify  the hiring of a bigger help desk team to deal with 1st line support requests instead of 3rd line (your Scrum team) shouldering the responsibility.

So yeah, loads of unplanned work is ‘bad’.

But not using your board to illustrate the situation, that’s far worse.

So even if it’s for the ugly, ‘bad’ blue coloured ,unplanned work.

Go ahead and colour me.





Ok that wasn’t necessary.

But I’m trying to play the role of a an angry white board.

That definitely wasn’t necessary.