The Road to Become PSM II – Part II

In this post, I will focus some terms and explanations on the “Scrum Guide 2017” which I believe is so important to understand the Scrum.

The Scrum Guide defines the Scrum as

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

It is easy to understand “productive, creative, highest value” terms. But, you may have such questions: “What are the complex adaptive problems” or “Aren’t all projects complex?”
Honestly, I accepted this term as it is for a while until I came across another framework called “Cynefin” in which the type of projects is explained so well.

Cynefin Framework

This framework says, If unknowns are more than known ones it is a complex problem.  In this type of problem, It is advised that firstly a)probe and b)get a sense and c)then respond. After examining this concept, “inspection”, “adaptation” terms in Scrum become more meaningful.

Simple” and “Complicated” are such problem types in which knowns are more than unknowns. It is mostly the things that you did the same before.

“Chaotic” problems mostly consist of unknowns in which you really do not know exactly what to do next.

If we continue the Scrum guide, we come across the “Empiricism” term.

Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an
iterative, incremental approach to optimize predictability and control risk.
Simply, we can do the things well that we did and experienced before. But what does iterative and incremental mean?
An increment is a piece of a whole like “a piece of cake”.
Iterative is a loop that consists of events, ceremonies, behaves and so on.
As you know, in each sprint, iteratively created an increment.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Inspection” and “Adaptation” are similar to “Sense” and “Respond” in the Cynefin framework.
 Transparency requires those aspects to be defined by a common standard so observers share a common understanding of what is being seen.
  • The Common language
  • The common definition of “done”

What is “done”? I understand it as a “checklist” which you should tick every after a PBI(Product Backlog Item) is completed. It is defined by the Scrum team and provides a common agreement.

When the values of commitment, courage, focus, openness, and respect embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
Every member of the team should commit PBIs in a Sprint, should be brave enough to handle hard problems, should focus the Sprint Goal and their tasks, should be transparent about sharing information, even troubles related to a task and respect other members.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of a working product is always available.
 Giving and receiving “feedback” so crucial for the success of the Sprints.
Product Backlog refinement(a.k.a. Grooming) is the act of adding detail, estimates, and order to items in the Product Backlog.
Image result for epic theme story
Theme, Epic, Story
Mostly the first written ideas in a product backlog become “theme” or “epic” size and not so suitable in a Sprint which is 1-4 weeks period.
If you look at the images above, you could understand the difference between “Theme”, “Epic”, “Story” and “Tasks”.
In a refinement session, Product Owner and Development Team create slices (Story) from big Epics, add enough details.
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Sprint Goal is so important term. It limits the Scrum Team’s flexibility in a Sprint. I mean that Product Owner may add or change any item in a Sprint of course only after getting an agreement with the Development Team. But, if this change affects the “Sprint Goal” it can not be allowed.
If Sprint Goal becomes obsolete, the Sprint may be canceled only by Product Owner.
My notes on Scrum Guide ending here. Next, I am planning to share my notes about “Nexus Guide”.
See you 😉

Also published on Medium.

Leave a Reply

Your email address will not be published. Required fields are marked *