Scrum, is a framework to address complex adaptive problems while creatively and productively delivering products of highest possible value. To start doing Scrum, all we need is 3 Roles, 3 Artifacts and 5 Events. These are the 11 essentials of Scrum. Then, there are rules and guidelines described throughout the Scrum Guide that bind these 11 essentials together.
However, while implementing Scrum, I have often found that people get confused between what are guidelines and what are rules of Scrum. In this post, I will point out few rules that would help you further explore the subtleties of Scrum Guide.
Here are few of the rules for you to think upon, spread subtly throughout the Scrum Guide.
Rule #1 : Product Owner is one person, not a committee.
Explanation : Product Owner is the value optimizer for the product. If there are multiple people who are taking shots at what maximizes the value of product and never come to a shared understanding then it is difficult for the development team to get started. This impacts the overall product development. Having one person, accountable for the outcomes; makes it explicit that the direction provided by this person needs to be followed.
Rule #2 : Every event is a time-boxed.
Explanation : Time-boxing helps team to have focus and work collaboratively, creatively and productively to create a potentially releasable “Done� increment. In absence of time-box Scrum Team may fall prey to what is commonly termed as “Student Syndrome� i.e. planned procrastination. This means, if not time-boxed Scrum Team may delay its development and other processes to last possible minute. This will force them work late-nights, weekends to meet delivery dates, which in turn will dampen their morale. Neither of which is good for team’s health or valuable product delivery.
Rule #3 : Purpose of Sprint is to create “Done� increment.
Explanation : One of the key agile principles is – Working software is the only measure of progress. This principle is an integral part of Scrum framework. If we are not able to create a “Done� increment at the end of Sprint we are not doing Scrum. Having a “Done� increment creates transparency, provides empirical data for the Scrum team to inspect and adapt, its future course of action.
Rule #4 : An Increment needs to be in a potentially releasable “Done� state all the time.
Explanation : Whether to release the product increment to production or not is the sole decision of the Product Owner. However, if the Product Owner chooses to release to production and the increment is not in a “Done� useable state; will the Product Owner be able to release it? Of-course not. Hence, the Development Team has to ensure that the product increment is always in potentially releasable “Done� state.
Rule #5 : Only members of Development Team create Increment.
Explanation : Have you ever inherited code from other developers or have you looked back at a code that you might have written couple of years back? How does it feel? I hear you say – we could have done a better job. Now consider there are people outside of your Scrum Team – who do not know what is your Definition of Done, who do not know what development standards you follow, who do not have same experience as your team with the product – how would they impact the overall quality of the product increment? Thus, only the members of Development Team are allowed to work on the increment; they can always self-organize and consult other SMEs, experts as needed.
Rule #6 : Sprint ends when the time-box expires.
Explanation : Sprint is a container event that creates cadence for the Scrum team to focus on creating a potentially releasable “Done� increment. Altering the length of the Sprint all the time, just because the Development Team has finished early or cannot finish it’s work on time will hamper the cadence. This, in turn also will impact the capability of Product Owner to make forecasts and create reliable plans.
Rule #7 : Sprint length does not change during execution.
Explanation : Same as Rule #6.
Rule #8 : Only Product Owner can cancel the Sprint.
Explanation : Product Owner is the value optimizer for the Product. This person has the accountability to ensure that the work Development Team is doing maximises the value of the Product. If the Product Owner identifies that the efforts put by Development Team in creating the “Done� increment will not add any value to the Product then only PO can take the decision to pivot and have the Development Team work on something else that would enhance the value for the Product.
If there are other people who are allowed to “cancel� the Sprint, there would be an utter chaos, as everyone will try to “cancel� the Sprint if they see their suggested work is not on the Development Team’s Sprint Backlog and the Development Team will loose focus on what needs to be worked upon.
Rule #9 : Sprint is cancelled when Sprint Goal becomes obsolete.
Explanation : Sprint Goal is an overarching objective that helps team to focus on what needs to be done through the Sprint. Scrum Team is committed to meet the Sprint Goal. The Sprint Goal may be impacted by many factors – market conditions, customer feedback, technology changes, competitor release – and when this happens, working towards the same Sprint Goal might not add any value. The Sprint Goal may no longer provide the same business results that we expected at the start of the Sprint. This makes the Sprint Goal obsolete.
This is an important inspect & adapt situation. Living by the agile values, it is time to “Respond to change over Following a plan�.
Rule #10 : Quality is not compromised during the execution of Sprint.
Explanation : Quality is a key to deliver valuable software to customers early and continuously. An Increment which has no quality is opaque and is difficult to inspect & adapt. As a result, every increment has to suffice the quality standards.
Conclusion : The 10 rules described above are sacrosanct and never should be broken. Breaking Scrum rules impacts your Scrum implementation adversely. There are many more such rules described throughout the Scrum guide which are essential for implementing Scrum in the right way, to create maximum business impact.
0 Comments