Viewing entries tagged
failure vs. success

When Sprints End Badly

Comment

When Sprints End Badly

Of course it’s going to happen. No matter how good an agile team is, eventually they’ll have a tough sprint and something bad will happen. They’ll miss the work they committed to in the sprint and some of it will need to carryover to the next sprint.

Mike Cohn had this to say about demonstrating that work in the current sprint in his December 10, 2015 newsletter:

A standard rule in sprint reviews is that the team should show only work that has been completed. This rule prevents a team from feeling that they've made more progress than they really have. Additionally, it avoids any risk that attendees leave a review confused about what has really been completed.

And so, teams are told they cannot show slides or partially finished work.

This is a great rule. But, just like my daughter tells me about her curfew, some rules are meant to be broken.

And so I sometimes break the rule about only showing finished work. A sprint review often brings together important stakeholders who are rarely together otherwise. That is a wonderful opportunity to ask them collectively, "What do you think of this screen [or other work] that is in process?"

It would be a shame to forego this opportunity just because of a Scrum rule.

 

Mike echoed my own advice for teams. But I usually adopt a harsher, no review posture, and Mike’s newsletter forced me to reconsider that advice.

I want to explore several aspects of sprint work that weren’t all covered in his newsletter.

Comment

Comment

The Agile Project Manager—Getting out of Jail Free

I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.

Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:

If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?

Comment