Why Shouldn't I Show Half-Complete Stories in the Sprint Review?

18 September 2013



We all know that the sprint review is meant for showcasing your work that you have completed in last sprint. It's all about improving the product by getting feedback from users. The Definition of Done (DoD) is what we use to determine whether a story will be included in the review, so what about a story that is partially complete and that the team wants to showcase? What's wrong with it? It's all about getting feedback from the user, to make the product better, right? 

Let me tell you the story of something that happened recently on the project I am coaching. The team was discussing a story they wanted to showcase in the review. The story was only dev complete and no testing had been done, but both product owner and lead dev insisted that it was a great idea to show that story as it would create interest among the stakeholders.

Against all the advice, the team included this story. The story was about a key financial data page. The review started, there were many senior executives in the review, and they all had vested interest in the project. Among the stakeholders, the chief financial officer (CFO) was also present. It so happened that this incomplete story was close to his heart.

During the review, the team explained that this story was partially complete. The CFO, who was, as always, busy checking emails and replying to them on his Blackberry, occasionally looked up to see what was getting demonstrated. He got really excited looking the financial data page but unfortunately hadn't paid attention to the message about that story being partially incomplete.

The next day, the team received a phone call from the CFO, who said that he was really impressed with what he saw and, on the strength of that, he had talked to the head of marketing and promised that this page would be available in production over the coming weekend. Then he asked the team whether, as the work was complete, they would have any issues getting it in production that weekend. Oops!

Try explaining now to the CFO that the story was incomplete.

After lots of discussion and looking at the work-around, commendably, the team went to the CFO and explained. He wasn't impressed in the beginning but then he understood and pushed the release to the next sprint. (Now, that you don't see very often.)

I am actually thankful to the CFO that he helped the team learn the hard lesson that I couldn't teach. Now team only shows what is really complete. I guess they know the value of DoD and transparency.
 
 

Article Rating

Current rating: 0 (0 ratings)

Comments

Glen Wang, CSM, 9/18/2013 3:24:43 AM
I see:
# 1: incomplete story demo leads to miscommunication.
# 2: the CFO doesn't respect (listen carefully).
Rajeswari (Raje) Kailasam, CSP,CSM,CSPO, 9/20/2013 9:48:35 PM
Vinay, thanks for sharing. Here are some thoughts:

Lessons for the Product Owner: Needs to be more actively engaged with the product, stakeholders. Learn to priortize stories based on business value. What if this particular story actually created more business value to the product? And what if by engaging with the CFO this team actually gets better in delivering most valuable features? I would love for a CFO of a company to acutally attend iteration demos, it is a great feedback that Scrum is actually working for this group.

I see a lot of opportunity for learning for the product team here especially with prioritization and understanding business value.
Vinay Tripathi, CSP,CSM, 10/7/2013 7:35:55 PM
@Glen, spot on, miscommunication is the biggest source of failure in Agile.

@Raje - Thanks. yes, the more the PO is involved with the development team the better the outcome will be.
You are right, sometime the priortisation of stories have to be based on multiple factors, senior leaders buy-in is one of them, only thing is - plan for it :)

You must Login or Signup to comment.