The Product Demo
In my first Scrum Diary post (“The Scrum Diaries – #1: Steps in the Right Direction”) I wrote about the first product demo we conducted for our business partners. At that time we discovered that there was actually another team of folks who primarily used our application. It was suggested that we conduct another demo for the broader team. That has been accomplished. It proved to be highly beneficial to both the development team and the business users. Our shared understanding of what we are building was enhanced all around.
In preparation for the second demo, our Product Owner put together a spreadsheet of all the screens in our application. She asked the business folks to rank their frequency of usage for each screen. She also asked for suggestions for improvements of current functionality.
Right off the bat, before we even held the demo, the response to the frequency of screen usage request revealed a lot of good information. The biggest reveal was that 15% of the screens were no longer used! This was one of my fears. It’s a huge application that we are rewriting. When I first joined the team, I asked the question, “Are we sure they use all these screens?” Looks like my hunch was right. We already rewrote three of the unused screens. At least we have better knowledge now and can avoid doing more unnecessary work.
Knowledge Flowing Via the Demo
A developer on our team gave a demo of the most recent work we had done. It didn’t take long for the business folks to make suggestions for changes and improvements. This produced a good list for the development team to work on.
The demo was helpful to the business users because part of what was shown was brand new functionality. They got a better understanding of the workflow and the new gadgets on the new screens.
Here’s where I noted a bit of disconnect in the overall product development process. When business representatives are responsible for making decisions about an application, but they are not the primary users of the application, requirements may not be the best for the development team to produce the best value in a product. Ideally, the shorter the distance between a user and a developer the better! Likewise, the more frequently a developer has interaction with a user in regard to a product, the closer that product turns out to be what the user needed and the outcome is greatly improved. We need more transparency and less middlemen.
Step one: get the suggested changes into the backlog.
Step two: get the next demo on the calendar!
Step three: help all parties understand the value of conducting a Sprint Review during each sprint. There is often a complaint that no one has time for yet another meeting. But can we afford to not have time? How much time did we waste rewriting three screens that didn’t need to be rewritten? How much time did business users waste while doing their jobs with functionality that they would suggest be better if someone would just ask them? We can’t afford not to inspect and adapt on a more frequent basis.
(The Scrum Diaries are accounts of my experiences with Scrum teams during an organizational Agile transformation. There have been, and continue to be, many bumps in the road along the way. We are learning and growing together as a team. I am a certified Scrum Master (PSM I) and a developer. I fill both of those roles on my team. These Diaries primarily address topics related to Agile and Scrum.)