First Sprint Review But Nothing to Demo
As Scrum Master, I'm conducting the team's first Sprint Review. Most on the team are new to Scrum. And our Sprint has been bumpy.
As it comes to a close the developers are not expected to finish their task, so I won't have a potentially shippable product increment out of the Sprint .
What approach should I take with the Sprint Review?
Difficult position to be in. The Scrum Guide states that the Sprint Review is to 'inspect the increment and adapt the product backlog if needed' so at least the backlog can be collaboratively discussed.
One of the bullet points states 'The Product Owner explains ... what has not been Done' so again this can be done.
It might be useful in that you have to give the customer some feedback anyway and it's better to communicate more than less. Will also set up for a better result at the end of next sprint when, hopefully, there will be an increment.
Presumably your team has accomplished some work that has value, towards getting the product shipped. What decisions did the team make during the Sprint? If you spent time understanding or researching the problem to be solved, show the result of your research. If you spent time figuring out how you'll all work together, demo your team communication plan, schedule for ceremonies, team working agreements, coding standards, branching model, qa plan. Review your Definition of Done. The process stuff affects the product. You're building a good pipeline for increments to pass through. The first Sprint is a perfect time to demo that.
Good approaches. Certainly I want to bring value to the Sprint Review in some fashion. I suppose the upside for my often impatient team is that it can be a short Review.
> What approach should I take with the Sprint Review?
The very first thing to do is to coach the team to prepare for the Sprint Review in the first place, and to allow enough time for this prep. It is *their* review, with the PO and invited stakeholders, of *their* work.
> I suppose the upside for my often impatient team is that it can be a short Review.
Putting the Sprint Review aside for the moment, how do you intend to approach the Sprint Retrospective?
As it's your first sprint, don't expect too much of it. Your team is new to the scrum way of working and it's perfectly OK that your first one has teething problems. We can't expect a newly formed soccer team to score in the first 15 minutes of the game either...
There are a few things to consider:
- is this project suitable for scrum in the first place? Can the project be sliced in 'value delivering' increments? I like to compare it to a 4 course meal with an Appetizer, Soup, Main and Dessert. Can we group and deliver our user stories in this way? That would be an ideal scum project. If you're cooking a one pot meal then it doesn't really make sense to demo that the potatoes are cooked half way and the carrots are sliced. It doesn't really add value. But delivering an appetizer makes the hunger go away and people are looking forward to getting some more when the waiter shows up next time with the soup.
- As everyone is new, how comfortable is everyone on the team? Are they honest in the daily scrum? Did they mention their issues. Do they themselves consider these as valuable or just a pain in the backside.... as just another way of micro-managing. Are they comfortable with self-managing or do they expect someone to tell them what to do?
- were the user stories too big? was the estimate fair?
- did the requirements change during the sprint?
These are just a few things to consider in your review. Don't give up :)