How to handle issues that are part of the backlog, solved in the weekend and are not part of current Sprint in Scrum?

Question

There are two issues on the backlog that I want to solve this weekend, that are not part of the current sprint.

According to me it is fine to work on this issues as I solve them in my spare time and my work time, i.e. 80 hours will be spent on the issues in the sprint.

Is it correct that it is fine that I solve two issues that reside on the backlog as it is not conflicting with the time spent in the office and two when I have solved these ticket I could close them as solved and the backlog will get smaller?

Answer 1

There's a lot wrong with this idea.

First, everything from Sprint Planning through the Sprint Retrospective is part of a Sprint. Also, a new Sprint starts immediately when a Sprint ends (although, in my experiences, I've typically seen the Sprint Review and Sprint Retrospective in the afternoon and then Sprint Planning the next morning, with a handful of working hours between them). All time, including weekend and holidays, is part of the current Sprint.

The Sprint Backlog is something that has been agreed upon by the Development Team. A Sprint tends to be defined by the Sprint Backlog and the Sprint Goal. During Sprint Planning, the team should have looked at the ordered Product Backlog, determined what items could be done this Sprint, made some kind of plan for getting it done, and then defined objectives that guide the Sprint and help focus the team.

Given this, I would have concerns about just working extra hours without telling anyone (preferably in advance), even if it was on planned Sprint work. If the plan was built around a specific capacity and people work additional hours, that's going to throw off planning for future Sprints unless it's accounted for. There could also be other downstream implications with respect to testing, deployments, change management, customer needs or expectations, and so on.

I would suggest that working outside of working hours is a violation of the principles of Agile Software Development. One of the principles is about sustainable development - the pace that the team is working should be maintainable indefinitely. Working weekends on unplanned work is not sustainable in the long-term.

In short:

• Don't work more than you've planned for a Sprint. Even if you are falling behind, work with the rest of the team and the Product Owner to decide what the best thing to do is.
• Don't work outside of the Sprint Backlog. All of your planned capacity and effort should be to realizing the Sprint Goals.
• Keep the underlying principles of Agile in mind. Sustainable pace is necessary. Not only does it prevent you from burning out, but it leads to better estimates and plans.

Answer 2

Here's how my team deals with "off-hours" work:

• We recognize that several members of our team, but not all members of our team, like to program during their free time on weekends and evenings.
• We believe that, since it's the developer's free time, they are free to choose issues that are interesting to them, even if they are not the highest priority issues for the business.
• We recognize that neither the individual developer, nor the team, should be on the hook for needing to complete regular sprint work during their off hours.
• We recognize that all work, regardless of whether or not it's done on-or-off hours needs to meet our Definition of Done and be held to our team's quality and standards.
• We do not allow off-hours work to be a developer's way of claiming all of the interesting issues from the backlog.

Dealing with points/development time

You don't mention what sort of velocity-tracking system your team uses. One key issue with off-hours work is that you don't want you or your team to be on-the-hook for always needing to work weekends in order to meet the sprint's obligations. Here's how we deal with this:

• We use points to track our velocity through the sprint. Since we don't want any of our developers to be obligated to work during their off-hours, any work that is done outside of the workday is considered to be 0-points, even if it has been estimated much higher.

Completing the Issues

You also don't mention what 'additional' work, beyond development, needs to be completed in order to call an issue complete. Again, my team's example:

• In order to meet our Definition of Done, off-hours work will need to be peer reviewed, tested, etc. These things, since we require them to be completed by other developers, will be added to a later sprint with only a point estimate for the amount of work remaining.
  • Business prioritizes the remaining work on the issues, just as they prioritize the rest of the backlog. Often, because much of the work has already been done, they'll move the remainder into the next sprint. Sometimes they will not.

---

In my experience, developers like to develop. Telling them "no, we don't want you to do any development work that you're interested in during your free time" is a losing proposition--especially if they're not allowed to contribute to open source or other projects because of their position in your company.

Look at your sprint process, you may be able to find a way, like we have, to allow your developers to work on the more interesting issues without negatively impacting regular workload and quality. The keys are:

• To ensure that a developer's weekend work doesn't obligate that developer, nor anyone else, to regularly work weekends, and
• To ensure that even weekend work is held to the same standards as the rest of your software.

Answer 3

Wether or not coding in your own time is appriciated, the problem isn't the coding per sé. The issue is that the developer may not see the whole picture.

How does the change get tested, promoted, approved, released, supported? Is testing the change also done by the same developer, in his/her own time, or is that effort added to the team?