Should Scrum Teams be Dedicated to a Single Product?
Should Scrum teams be dedicated to a single product? The truth is, there's times when you want a dedicated team and times when you don't. Let me explain!
Should Scrum teams be dedicated to a single product? The truth is, there's times when you want a dedicated team and times when you don't. Let me explain!
Good software solves the customer's problems, but to provide the right solution, you must start with the right problem.
Here's 5 steps you can take as a manager or ScrumMaster to help DOUBLE your Development Team's performance (#5 is a shocker; it's easy but SUPER non-intuitive!)
Effective Scrum use is more than Sprint Planning, Daily Scrums, and so on. To see a big difference in your team's Sprints, make these workflow changes.
Analysis, design, coding, and testing are done constantly rather than in phases, meaning testing ISN'T just a phase but an ongoing part of Agile Development.
When I teach or coach people about Scrum, we talk about self-organization, but the importance of self-organizational principles cannot be understated.
Specialists with a particular skill can get stretched thin! But there's ways to solve this dilemma other than assigning them to ten Scrum teams at once.
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!