Paul Henman Dilbert,funny,scrum Time waits for no man

Time waits for no man

It seems that this blog is largely becoming a place where I just re-post Dilbert cartoons, but that’s not my aim … however, Scott Adams is just so spot on sometimes!

Dilbert.com

I’ve been in the situation (as I’m sure most PMs have) where the team says there’s just not enough time to get everything done, so I try to explain to the Product Owner that we need to cut (i.e. postpone) some functionality or we can’t deliver, only to be told “I need it all or there’s no point in delivering it”.

In some cases I’ve succeeded in getting the PO to see the problem and agree to moving some functionality to a subsequent iteration; in other cases, the PO dug their heels in and the team failed to deliver and so the story rolled over into the next iteration*. Fortunately the majority of the team members I’ve worked with have had enough professionalism to not simply cut quality in order to finish on time.

*Yes, these two outcomes do somewhat amount to the same thing: what the PO wanted (and the team committed to delivering) are finally delivered at the end of two iterations. The team’s velocity is the same whether the Story Points are split up and delivered in two sprints or if they deliver zero and then everything.


[In the above burndown charts, the velocity after Iteration 11 is the same regardless which route is taken when the issue arises during Iteration 10.]

The major difference, though, is how the Product Owner and the team end up feeling about what they’ve delivered: in the first case there maybe a sense of disappointment that the team can’t deliver on their original commitment (although hopefully this is tempered by an understanding of what caused this and a determination to avoid it in future); however, in the latter example, there could be an air of mistrust and resentment.

At the end of the day, everyone needs to work together in an open and collaborative manner; sometimes that means accepting that things do always go as planned, looking at what can be done to recover the situation, agreeing a revised plan, and moving forward. Oh, and don’t forget to look at why the problem arose in the Retrospective!

Related Post

PrioritiesPriorities

How do you identify a high priority task? I like this answer, found on Merlin Mann’s website: In Scrum we tend to see tasks (the work breakdown that a team