Scrum in a Business as Usual (BAU) Team

ZXM had been working on a project with a client using Scrum to help them set up an Intranet redevelopment project. The transparency and collaboration that the manager saw emerging out of the intranet project was very appealing to him. He decided that it might be adaptable to his BAU team.
The BAU team  always seemed to have a “backlog” of work that never got done. The main issues were:

  • No collective process for them to process business user requests
  • New work coming constantly coming in from the business
  • Team not sure of which work was important, urgent or ranked higher
  • No collective processes to handle BAU as well as project work
  • Small team but working in three streams of activity
As a result, they started a bit of each project but never quite got anything finished.
Using a psychology based learning model of competency, within three months we were able to take the team from Unconscious Incompetence to Unconscious Competence.
Why was this approach success for the BAU team?
  • Scrum gave the team radical visibility of what was coming up from conversations in standups and backlog refinement.
  • The traceability of stories to themes and Epics gave the team a sense of where their work fitted into the bigger picture.
  • Knew to refine the backlog with the Product Owner in order to work together to establish the definition of done (DOD), estimations and tasks
  • Able to better understand and estimate BAU velocity and project velocity
  • Now had a process to deal with business requests and how to determine order/priority of work in context of the product backlog
As a result the Team asked t0 be involved in work across old silos and the product owner was comfortable to move to only stating the WHAT and not the HOW to his team.
  • Better understanding of commitment to take on a product/story in a Sprint
  • Collaboration and pairing across old silos occurred to complete tasks
  • Not silos of 3 streams — a single team with a single, shared vision of how to get their work done

About the author

Related Posts:

Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.


How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.


How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.


How do I run Sprint Planning?

Sprint Planning is one of Scrum’s five events. There’s more to it than just making a plan. Importantly, as an action of empiricism, the team should be inspecting the Product Backlog and adapting, and creating, a Sprint Backlog that makes their plan to achieve the Sprint Goal, and deliver a potentially releasable Increment, transparent.

search previous next tag category expand menu location phone mail time cart zoom edit close