Keep Your Sprints Short
Scrum teams are responsible for choosing sprint length and are encouraged to experiment with different sprint lengths, but shorter sprints are easier to manage.
Scrum teams are responsible for choosing sprint length and are encouraged to experiment with different sprint lengths, but shorter sprints are easier to manage.
In this article, we'll discuss how a team bares responsibility for the Sprint and what should be done if they can’t get everything done they committed to.
Bigger requirements are more complex, which typically have greater risk, which leads to more cost and/or waste. In other words, bigger is DEFINITELY not better!
One of the worst things we can do to our teams is allow too many changes to the content of the Sprint after the Sprint has been planned.
Scrum Sprints provide empiricism, part of the Agile core beliefs, which is why extending a Sprint is never a good idea!
Many Scrum events seem simple, but aren't. The Daily Scrum seems to be the event that causes the most problems for teams.
The fastest team productivity killer is working on 3+ backlog items at once. You'll end up with a team that's great at starting work, but lousy at finishing it.
Teams that "Swarm" backlog items find it's a better way to get work done than approaches that lead to handoffs and continuity loss.
It's critical everyone on a new Scrum Team starts with the same understanding of Scrum. A learning structure called “ShuHaRi” can be related to teaching Scrum.
Many organizations transitioning to Agile Development suffer from a preconceived idea that coding tasks and testing tasks should be seen as separate activities.
Plan your transition to Agile Development for the long haul. It's more than just code. Treat it that way!
Measuring Scrum Team productivity is something nearly every organization wants, but performance metrics should really only be created under two conditions.