The Order Is Set

Today we will continue with the rules. However, unlike in previous articles, even the last one, we could sum this group up in one topic: order setting.

We're going to talk about a time when the Product is not only being developed, it's already available to Stakeholders. This means that we are already at the stage where support for the existing Product is needed. Any Product may still contain bugs, or bugs may occur when the product is used. Therefore, it is in the best interest of the Developers to at least fix/remove some of the bugs. But in what order? We'll start with the most serious ones.

 

User Stories representing blocking bugs (bugs that have no workaround and block Stakeholders from work) are immediately presented to the Developers in an emergency refinement session.

The highest priority is given to blocking bugs. Since there is no workaround for them and they block Stakeholders from working, they need to be resolved as quickly as possible. In terms of process, we want to get them into a Sprint as soon as possible. In order to do so, they need to be refined (ready). Waiting for a regular Refinement could slow down the resolution of a given problem considerably, so we can/should take advantage of an emergency refinement session.

 

User Stories representing critical bugs (bugs that have a workaround that is not acceptable for a prolonged period of time by the Stakeholders) are presented to the Developers in the next Daily Scrum meeting.

Critical bugs have a lower priority. For a little while, Stakeholders are able to accept their existence, but it is not advisable to postpone resolving critical bugs for a long time. Developers are informed of them at the next Daily Scrum meeting, which is usually no later than the next working day after their occurrence.

 

Standard bugs are entered at the beginning of the Product Backlog and the Product Owner is notified of their presence.

The last category is not subject to urgency; standard bugs are handled together with other requests. For simplicity, so that they don't get lost somewhere, they are placed at the top of the Product Backlog and the Product Owner is notified of their existence. It is up to the Product Owner to decide with what priority they will be processed and where they will be placed in the Product Backlog.

Now, we come to the last rule in this batch:

 

Developers develop User Stories in a Sprint in the following order:

  • Blocking bugs
  • Critical bugs
  • Planned User Stories and bugs with deadlines (in order of deadline closeness)
  • Planned User Stories and bugs
  • Unplanned User Stories and bugs

Yes, it's good to note that User Stories in a Sprint can be processed in a certain pre-agreed order. Why we start with blocking bugs is described in today's first rule. Next are critical bugs; these are issues that make Stakeholders’ jobs significantly more difficult. Since the Product is primarily designed to make the Stakeholders' jobs easier, these come second.

Planned User Stories (and bugs) with deadlines are placed before other planned items for one simple reason: the need to meet the deadline. We talk more about Deadlines in our series of articles that starts with this one.

The last in line are unplanned items. Why last? These are User Stories that have been added to the current Sprint and are not part of the commitment; for example, when other User Stories are already Done or blocked and the Developers have spare capacity to do more work. If a User Story from another category can be unblocked, its completion takes priority.

 

There are only a few rules left in the Development cycle, which we'll talk more about in two weeks.