Backlog Refinement is a critical part of good practice in Scrum. Refining the Product Backlog ensures that the Team and Product Owner have sufficientl
When things get stale, ROTI is a simple pattern for team feedback that places the ownus of actions for improvement back on them.
What does a Scrum Master do all day? Run events and facilitate meetings? The Scrum Master role has evolved greatly over the last 20 years and now encompasses leadership, coaching, and growing agility through Scrum.
The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).
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.
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.
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.
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.
When setting up new agile teams we have found that starting small with the basics and adding patterns as they start to develop capability has helped us get new teams up and running within 2-3 days and acheive a baseline of agile capability within 3 months
© 2019 All rights reserved