Sprint review is an event in scrum, which is used to review the increment developed by the scrum team. The purpose of this event is to actually inspect the increment in light of product goal, market conditions and feedback from customers and adapt the product backlog to meet the changing market needs.
Sprint review would not only trigger new items in product back, it will most likely impact the order/priority of the backlog and it may also trigger changes to the existing backlog items.
Unfortunately when sprint review doesn’t quite happen as intended by scrum guide, it is likely that the team will miss on inspecting and adapting against its product goal and also likely to create increment which is not quite releasable or valuable for customers.
Here are the sprint review anti patterns
- Sprint review as demo to Product Owner (PO) – a lot of teams run their sprint review as if they are seeking POs approval for the work done. So they conduct a demo to PO of each and every work done. When the focus is to seek approval through the demo purpose, the core purpose of sprint review is lost. Teams tend to become more focused on impressing PO. In the process, it is very likely that the conversation of sharing authentic feedback to each other in light of changing market conditions, gets lost.
- No stakeholder in sprint review – this is another most prevalent anti pattern for sprint review. No stakeholder in sprint review, would miss out on getting feedback from stakeholders and it would also reduce transparency significantly. Both of these can have significant consequences for the product. No stakeholder in sprint review may result in consequences such as lower stakeholder support, missed market feedback, improper prioritisation of backlog items, missed business opportunity or risk or lack of funding support.
- Focus on velocity in sprint review instead of reviewing increment – this usually happens when leadership is more focused on tracking team velocity and probably comparing team velocities across teams(even though the units are not comparable). While tracking velocity is not a bad idea, sprint reviews need to be focused on reviewing the work done and creating a valuable and shippable increment.
- Incomplete stories split, so teams can count velocity for the work done instead of focusing on completing the story as done by “definition of done” – this is one of the consequences of management tracking and comparing teams based on their velocity. Splitting stories in order to account the velocity for the work done, usually results in horizontal slicing of stories instead of vertical slicing. Stories split to merely account for velocity, may not quite be a value add to customers. The focus in review should not be to improve velocity count, instead teams should review the items completed by definition of done.
- Look for whose code failed when sprint review runs into defects – this happens in teams which have low team ownership and empowerment. Running into defects is likely for a system at any stage, including in reviews, but when you run into defects in front of stakeholders, it should not be a reason to pick and blame individuals. For a scrum master, the defects are a great opportunity to retrospect with the team and improve not just the code quality, definition of done and also team ownership.
- Sprint review is only attended by a few (senior) developers and PO – sprint review should be attended by the whole scrum team and the stakeholders but sometimes one can notice only a few members of the team dominating team decisions. Per scrum guide, there is no hierarchy in scrum, however every organisation operates within its own cultural boundaries. Sometimes scrum teams get infested with unspoken or hidden hierarchy. It may not be explicitly called out but it becomes visible by observing behaviours of teams. When only a few members dominate or are part of sprint review, chances are the sprint review is missing some crucial inputs and it limits the ownership to build a great product.
- No clarity around product goal – I have often discovered that team members working on scrum teams have no clarity on product goal – what are they developing and why? Most of the time I find the developers not thinking beyond the items selected for the current sprint. The underlying reasons for not being able to see the big picture or not even asking for the big picture could be many, however the Product Owner can always help the team zoom out and see the big picture and purpose behind the product development. In sprint review, this big picture can help teams inspect and adapt their product backlog and roadmap.
- Rewarding individuals for completion of stories – Rewarding specific individuals through praise is considered as a way to motivate people in most organizations. While managers have used praise for years to manipulate individuals by creating this extrinsic motivation. There are two issues that I would like to highlight
- This creates a situation where individuals start to manipulate situations to look good in order to receive the praise
- When praise is for an individual, this at times, triggers a kind of unspoken/hidden competition, which impacts the ability for the team together.
- Code review in sprint review – this is another weird kind of sprint review that I have seen. In order to show the work done, developers get into showing code. This discourages business from attending sprint review because they may not be able to follow code and also it takes the team away from the core purpose of sprint review of inspecting and adapting on product features.
- Sprint review without PO or with proxy PO – This usually happens when PO claims to be super busy and is literally unavailable for the team. Such situations usually happen when business hasn’t quite bought into agile and does not see value in dedicating a person to play a full time product owner role. In such situations, I have found business analysts designated as proxy PO. It’s kind of a work around however a proxy PO is not really a PO. Somebody who is playing a proxy, may have limited ability to review the product plus the actual PO missing review may end up in delay or miss certain critical feedback altogether.
- No sprint review altogether – Another interesting practice, which is usually a result of low or no business involvement through the product development. When business is not onboard with agile, they expect IT to develop a product and they plan their engagement only when things are near the release date. This is the waterfallish approach. As a result, the product development process misses out on critical feedback loops from customers. This can trigger significant changes, towards the end of the cycle, which will be a lot more expensive and also add significant risk to the product development.
- Presentation based sprint review – While I have found this practice pretty rare however I was surprised to discover a few times, a product owner doing review using presentation. This sprint review was attended by senior leaders of the organization, so the reviews would be quite tense, only a few would talk and share their thoughts. The product owner in this case was also tense and did not want the review to run into any buggy situation, so he decided to create a presentation. The challenge with presentation is that it does not quite bring out the understanding of how the real product will behave and it creates a false sense of completion, when the reality may be a lot different.
