One of the key responsibilities of a Product Owner is looking after the backlog and building and maintaining the Product Roadmap. The Roadmap is a great tool that provides a visibility regarding the Scrum team’s work and to materialize where the team is headed to. It’s a good practice to communicate the up-to-date Roadmap with the shareholders often in order to let them know which new features and bugfixes are planned over the coming weeks and months and to notify if there is a recent change on the planning.
We are running 2 weeks-long Sprints. At the end of the Sprint Review session, as the PO, I’m presenting the PBIs (Product Backlog Item) in priority order and ask openly to my line manager and other shareholders if we share the same understanding of priorities. From time to time chances are my management team and/or shareholders comment on the priority of PBIs and ask changes. On those instances, we altogether discuss about the motives of these new requests and get fully aligned. At the end of the review we as the team get either confirmation from the audiences regarding the priority order or have an updated list of priority. Here below you can see the ~3 months Product Roadmap of our team. (I’ve intentionally made it blurry for confidentially reasons)
Okumaya devam et “How to build, maintain and communicate the Product Roadmap?”
From my perspective, the beauty of Scrum framework is running Sprints for a short period of time (typically 2-3 weeks) and at the end of it being able to judge the team’s overall performance objectively. Setting a goal for a few weeks timeframe and going for it enables the team to get disciplined and stay focused. Historically, we had 6-9 months long projects with potential delays. This leads the teams easily jump into the comfort zone and adapt a relaxed and ‘take it easy’ type of attitude due to the long time for the project completion. Generally speaking, the human nature has a tendency to delay most of the work to be done towards the deadline. ( Remember your university finales :)) Therefore, setting digestible, S.M.A.R.T Sprint goals developing iteratively and incrementaly is an effective way to accomplish significant achievements within a certain timeframe.
Well, how does the team monitor if bringing the Sprint Goal to DONE status is something already secured or it is at risk ? Even though, it’s not mentioned in the Scrum guide at all, best practices propose “Burndown Chart” for that purpose. As the Scrum Institute put it precisely:
The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.
Okumaya devam et “How does the Burndown Chart help us to meet Sprint Goals?”
What should be the success criteria of a Scrum team? Is achieving the sprint goal sufficient or one should also take into account the total story points completed ? Perhaps it should be a mixture of those? Should we also keep on eye on the velocity? Apparently, this is somehow a blurry area of Sprint Framework, isn’t it?
As far as I understand, the Scrum guide didn’t specify this precisely. Here below I’m quoting the related section :
The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
Let me share my own point of view regarding the condition that defines the success or failure of the Sprint:
At the Sprint Planning event, the product owner should make sure that the Sprint goal is crystal clear for the development team. Ideally Sprint Goal should be a consolidation of interconnected items in an incremental manner that could allow the team to focus and collaborate effectively.
At the Sprint review meeting, the Scrum team and stakeholders try to validate if the Sprint goal has been achieved. In addition to that, we are also checking the percentage of the Story Points completed and the change in the original Sprint Scope. Among the 3 metrics ( Sprint Goal, percentage of completed Story Points and change on the scope) achieving the Sprint .Goal is the most important one. Typically if we agree upon the accomplishment of the Sprint Goal together with stakeholders, as the team we conclude that it was a successful Sprint even if we may fail to complete the targeted SPs. As a team we are actively focused on downsizing and consolidation of Backlog items so that the complete scope could be expressed as a single easy-to-understand Sprint Goal.
One of the most common discussions regarding the Scrum Framework is if there are too many meetings within a Sprint ? Is this allowing enough time for the development team to work towards the Sprint Goal ? Typically, there are 4 Scrum events defined at the Scrum Guide :
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective ( We call this simply as Retro :))
Let’s figure out the total number of hours spent on 4 events along the Sprint. We are running 2 weeks long Sprints and the scheduled events are taking 2 hours, 15 minutes/day, 1 hour and 2 hours respectively. Hence, the number of hours spent during the event is 7,5 hours within a Sprint. Considering each work day as 8 hours, this refers to almost 10% of the total Sprint time. Depending on the characteristics of the team, this ratio may go up to 15%.
As you would agree spending 10% of the Sprint time for the Scrum events is feasible. In return, the team makes the wise planning driven by the priorities, come together everyday to get fully aligned, share and demonstrate Sprint results with the stakeholders and finally have the opportunity for self-inspection and identify improvement points. If none of these meeting had exist during the Sprint, the team would still need to organize meetings to discuss all the details and probably would spent much more time. In essence, running Scrum events in such a structed way is serving well to the productivity goal of the team among others.