Ideally, before performing the Sprint Planning session as a team, the Product Backlog Items those will be potentially included in the next Sprint are supposed to be estimated in Story Points. The higher the priority of any Product Backlog Item, the higher is the expected maturity level of that particular PBI. Then, based on the average velocity data i.e. the average completed story points in the past, together with the expected capacity of the team for the next Sprint, the development team decides which PBIs should be included into the scope of the following Sprint. We, as the product owners are supposed to provide the right level of priorization and the overall direction to achieve a Sprint Goal before the planning session. This is basically how Sprint Planning works.
Nevertheless, Scrum teams may face scenarios where there may be strict deadline for a new feature or a solution. In other words, teams could face circumstances where the typical release planning could be not be applicable. To make it more concrete, let’s assume that the total amount of Story Points for a new to-be-developed solution is 100 SPs. Moreover, assuming that based on the proper planning done by PO according to the velocity of the team while preserving the projected capacity , it seems feasible that the team would require 4 Sprints in order to ship the solution. There are chances that, due to a certain reason ( Top Management expectation, natural deadlines such as Christmas, back-to-school season etc.) it may not be feasible to run 4 Sprints as the strict deadline does not allow such a period of time. Let’s imagine that for this example the deadline is just 3 Sprints away. Than the big question is how should a PO react if she/he encounters such a case ?
Okumaya devam et “How does it work in Scrum if there is a strict deadline ?”
One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.”
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
“User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.”
Okumaya devam et ““Working software over comprehensive documentation””
One of key metrics of a Scrum team is Velocity. Even though it’s not mentioned in the Scrum guide, it is still very useful for the Product Owner while planning the Scope of the next Sprint and defining a concrete Sprint Goal.
As the name implies Velocity (consider the team as a vehicle) is a metric calculated by averaging the total amount of Story Points completed over the number of Sprints within the same period. In practice, the velocity of the teams gets stabilized after a certain number Sprints are left behind. As the number of Sprints increases, the velocity starts oscillating in a regular rhythm.
Okumaya devam et “Velocity : Key metric to secure an effective Sprint Planning”
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?”
Let’s imagine a typical Sprint of 2 weeks duration. If the team is delivering software continuously since more than a year it means that the team had run around 26 Sprints past year. Do you think it is feasible that each and every Sprint has been finalized with success? Obviously, it is not surprising that a number of Sprints fail to accomplish the Sprint Goal. Well, even though it’s not the best scenario, a mature Scrum team is supposed to manage mentally and emotionally the consequences of a failed Sprint.
Every professional aims to be successful at personal level. Similarly, everybody enjoys being part of a winning, successful team. Nevertheless, it is very likely that a Sprint could not achieve the targeted Sprint goal and fails due to several reasons such as bad planning, dependencies, challenging Sprint goals, changing scope etc.
Okumaya devam et “How to handle a failed Sprint and how to avoid it ?”
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.