Do you respect the backlog?

We always strive to be more effective in how we build software for our customers, and today I was compelled to reach out with the following to my scrum teams:

The backlog ranking order is in place for a reason. Traditional waterfall software development projects have for years struggled to meet planned quality, schedule and content targets. The Agile software development recognizes the unique nature of uncertainty associated with software development, and gives us an approach to improve the governance and predictability for shipping quality software while building the content that target customers want. We do this by 

• QA: building quality targets into our definition of done criteria and acceptance criteria. This way any work that fails to meet DOD or acceptance criteria is not accepted and is not shipped. 

• Schedule: fixing the timeline. Sprint duration is fixed. Anything that is not accepted is not part of a sprint delivery and is not included in the shippable product (we can choose when we ship the release, but only after one of the sprints). 

• Content: we use backlog ranking to control what gets built as part of the release. When we run out of time, ranking ensures that we had enough time to build what we wanted to include in the shippable product and that we didn’t instead use that time to do something less desirable.

Generally speaking you should not begin work on any defect or a user story if you are also the owner of another open defect or an unfinished user story that is/are ranked higher. If you want to work on this because you disagree with the backlog ranking order, this is material and it is important that other people working on the release know; so just bring it up in our daily standup meeting, or reach out to me or your scrum master (in person, Flowdock, Skype, email, call, SMS). We can quickly discuss this and come to a shared agreement which can then be communicated and logged (e.g. in the Rally Discussion tab of the affected work item).

This also applies to any new work items popping up in our backlogs in the middle of sprints, i.e. items that we have not explicitly planned for during Sprint Planning sessions. If you open a new defect during the sprint or move a story or a defect from future sprints, please communicate/log this (e.g. by adding the explanation in the corresponding work item’s Discussion tab in Rally). Again, in general, the work on these work items should only begin when all the items planned for the current sprint are either completed or the work on them is blocked. If the unplanned item is critical for the sprint progress, we should discuss and if deemed necessary rank it higher on the backlog and (again) communicate/log our decision.

Although we are dealing with high uncertainty associated with complex software development, our business needs us to be more predictable in our ability to ship the working product. This is really important for our company's ability to operate as a well-run successful enterprise. Improving the following will help us get better 

• Transparency and communication

• The discipline and consistency in how we allocate our time during the sprints