Agile in Practice

Stefan 12. July 2015

Lately I heard the statement that a team would only show stories that had been finished during the sprint which kind of puzzled me. Why would some team come up with that idea? Well, I asked back and got: “That’s what Scrum says”! I honestly heard that statement many times before and you know the reason why? Because every ScrumMaster has at least heard that statement once if not multiple times without actually providing a real proof. If you then ask back where this would actually have been stated, us Scrum Masters get something like “in the internet” – arghhh. Now the ScrumMaster has to proof otherwise – that’s not fair, is it? 😉 Enough with that rant, let’s get back to the main point:

Should the team only present finished or “done” stories?

Let’s first look at the reasons why this would make sense:

• The team is proud of what it has done so it likes to present the things that went nicely.
• The stakeholders get a good view on what is potentially shippable.
• The team doesn’t like to blamed not to have finished what they have committed (or forecasted) to.
• The team doesn’t like to talk about unfinished stuff as there might be a lot of things that are still in the works and are subject to change.

Honestly, the third one in my opinion is the one the comes mostly near to the truth, which actually is pretty understandable. Many times teams have experienced in the past that they are questioned why something didn’t turn out as planned and people are looking for failures and then blame others for it. Not so in the agile mindset. Remember “fail fast”? And that we want to learn from the past?

Now let’s see what Scrum says and the root of what is officially is said in Scrum is the Scrum Guide (or maybe the Agile Manifesto). Here is a relevant excerpt of what is said about the sprint review:

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration..”

and

”

• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

”

Why it actually makes sense to show everything

Actually the above Scrum-statements are pretty clear that we do not only show something that is completely done.

• A sprint review is about inspection and transparency. It is about “what was done in the sprint” and not in the sense of having been finished but what has been worked on! How can we understand to adapt if we not look of what has gone wrong (besides of course what worked well! – let’s not forget that of course!)
• More precisely it is stated that the PO explains what Product Backlog items have been “Done” and what has not been “Done”. This is more than clear – the PO talks as well about things that have NOT been done!
• The Dev Team is also asked to tell what went well and what problems it ran into and how those have been solved. How can this been explained without talking about non-finished work which definitely is a part of the whole sprint “story”.

I personally feel that

• it doesn’t feel good to only have a show of success stories. It is just unrealistic and everybody knows that. Ups and Downs are part of life, so it is in sprints. Telling many good and some bad experiences feels much more serious than presenting “a show” to the stakeholders.
• the Dev Team should be proud of what it has achieved and therefore also show or tell about it (which kind of differs to the above statement that [only] the PO should explain… of course the team can also do that!);
• the Dev Team should tell stories and anectodes what it experienced and learned within the sprint. Many times these learnings come from surprise, the unexpected, failures and misunderstandings they ran into. Many times this is much more exciting and interesting to hear for the stakeholders than all those great success stories;
• the Scrum Team should be honest with their stakeholders as this finally will build trust and keeps them much more engaged over time.

So be brave

and tell it how it is: Tell about the good stories and don’t hide your learnings. Paint the full picture and you will be rewarded by stakeholders that will eventually trust you much more than you would ever think!

 

 

 

• Uncategorized
• No comments