How do you write great User Stories?
How do you create an Increment of work in Scrum? What has it got to do with the Product Goal and Definition of Done?
Backlog Refinement is a critical part of good practice in Scrum. Refining the Product Backlog ensures that the Team and Product Owner have sufficientl
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).
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.
There are a lot of misconceptions about what an Agile Coach is or isn’t at the moment. Are they the Scrum Master of a team? Does their role include coaching the team or is is something more?
Teams were bored with their Retrospectives. I was bored. They were just doing mechanical Scrum. Retrospectives are such a powerful tool to drive continuous improvement, so here’s what we did to fix the problem.
There are quite a few ideas circulating about what makes a good agile coach. Should they be a senior developer with excellent coding prowess? Do they need technical skills? Should they be something more? ZXM’s model is founded in contingency-based leadership and reinforces the need to take a product agnostic view, a non-software perspective, on how to support agile teams.
© 2019 All rights reserved