How to handle tickets during sprint planning

Question

I work in a flexible team.

We have a released product and we are still working on a future release.

Each sprint we get from 0 to 5 tickets to fix errors in the released product.

Our team consists of software engineers (to handle new developments) and software service engineers (to process tickets).

My question is how you consider service hours when planning sprints.

We currently have a story called a service buffer, where we devote several hours to resolving tickets. And we kind of use it as a buffer, so in the sprint, where we don't get any tickets, we use the clock in the buffer for development.

I feel that this is not a good flexible way to do anything, any suggestion?

Answer 1

The approach you mentioned is also being considered by Mike Cohn. Should history points be tied to the journal history of defects? where he writes:

Sometimes teams write a user history for this activity, for example: “As a user, I want to fix at least 15 errors” or “As a user, I want you to spend about 50 hours fixing bugs during sprints so that the application gradually becomes better” . Even a team that does not explicitly write such a user’s story usually includes a line on it to make flexible defects and bug fixes visible, as well as track it.

You currently have a story called a service buffer, where you set aside several hours to resolve tickets, which is something similar to what Mike Cohn said in his article, where he recommends assigning points to an error, fixing flexible defects.

There may be other options, such as

• Setting the time to fix errors in each sprint. It can be a given time of the day / week when each team member is dealing with errors.
• Including each error in the same sprint backup period, considering them as a partially implemented function. This is discussed by Mark Summer in Error Management in Scrum .

What to do in case of emergency / correction?

You need to evaluate the criticality and effort required to correct this urgent error. The product owner can decide if the entire team will reset everything and begin work on the fix. The reason is that the customer is always in the first place, and if the delivered product does not provide the expected value , then it makes no sense to add additional functions to the incomplete product. No structure / methodology prevents you from dealing with exceptional cases or dictating to you to ignore critical issues. Thus, the current sprint can be canceled or if the correction can be processed by one (or some) team members, then the function or error from the current sprint can be replaced by urgent correction of errors.

In the words of Jeff Watts from Production Support and Scrum :

If the problem is a genuine emergency, then the product owner must have to play an "emergency card" if he is aware of the costs of this - not completing the points that we planned, and potentially jeopardizing the goal of the sprint.

The product owner can use any of three options:

• Add an urgent defect to the lag because he / she decided that the current sprint goal has a higher priority
• Add an urgent defect to the current sprint because it is critical enough that it can even jeopardize the sprint's goal.
• Cancel the current sprint, perform the fix, and then run a new sprint.

Answer 2

In short, I would put the error (s) as an element of product lag (PBI) and set priority over other PBIs in product lag. Thus, you can always be sure that the most important things will be done first.

Part of the unwritten Scrum contract is that the business agrees not to interrupt the development team. In part, this can improve performance.

If you get a hot / urgent ticket that CANNOT wait for the duration of Sprint, you need to convince the Product Owner, who will then negotiate with the development team to best introduce the hot item.

However, this should be an exception, not a rule. If, as you mean, you get a lot of errors to fix, I will be tempted to run the maintenance / repair patch using a separate command that uses KanBan, not Scrum.

Answer 3

I agree with you that this is not a very convenient way to do something! The question you ask is your real goal to plan hours of service or to ensure the optimal work of your team, working both with user histories and with defects while using high-quality code, including bug fixes?

I would take it one step further from what Derek suggested - and use Kanban AND Scrum together - Scrumban is groping more and more! Since you said that you can have from 0 to 5 defects in any sprint, it is obvious that your “demand for failure” is variable, and therefore it is necessary for your “process engineers”. What do they do when there are 0 or 1 or 2 defects? I believe that they also contribute to the “demand for value” - new user stories.

This is where Kanban shines. While the actual design of your Kanban board needs to be reviewed by your team, you can start with a simple 2 swimming panel that reflects your current process to complete your work. Below is a simple example -

Here you have all your engineers to work in both lanes. As the work proceeds, depending on who can accept it and MAY accept it, they work on it and work on it. You are still doing sprint stuff in Staging - and deploy the package in one go.

In addition, you can have completely separate bands for user stories and defects -

Here again, all your engineers are working on objects in both lanes. However, you have the flexibility to deploy defect fixes as soon as they are fixed and accepted by the client (if applicable). Given the need for value, you continue to perform the same process as you do now, and deploy when each sprint is completed.

The benefits of any of these approaches are

• You get more people to work in any situation.
• You potentially get faster response time, better SLA performance, for defects.
• You get a happier team where everyone can work on new material. Most engineers do not want to be the “maintenance” guys :-)

Of course, this is based on a basic analysis. If you are not familiar with Kanban or Skrumban, you should read the books of David Anderson (Kanban) and the documents of Kori Ladas (Skrumban) and some others, such as Yuval Yere, Jim Benson, Masa Maeda and prepare for the best. You can also contact us at www.swiftkanban.com and we can also help.

Hope this helps!