Agile practitioners are aware that Scrum has three roles: developer, ScrumMaster and product owner. In his book “Executable Specifications with Scrum”, Mario Cardinal also discusses how you can use the role notion in Agile to better understand stakeholders that have a different perspective, a concept that is also named “personas”.
If Agile approaches are tools that allows to deal with uncertainty and change, they have often little impact on the management mindset that still requires to have deadlines proposed with software development projects. In this blog post George Dinwiddie discusses the usage of user stories for planning in Scrum projects.
Scrum, Kanban, Scrumban: there are many approaches to manage product development and project in the Agile software development world. It is a good thing to have multiple Agile tools, but you should also know when to use them. In this article Brendan Marsh of Spotify explains why his team dropped Scrum for Kanban just before launching their product.
Retrospectives are certainly one of the most important techniques used in Scrum as they form the foundation of the continuous improvement and adjustment to the context for the Scrum team. It is however not always easy to facilitate this activity with a bunch of software developers that are often mostly introverted.
What do home ownership and leveraged buyouts can teach us about how to use technical debt to our advantage in Scrum? How can we sleep soundly at night when we have accumulated mountains and mountains of technical debt? When is good enough good enough and when are we just deceiving ourselves?
“You cannot manage what you cannot measure” is an old adage in the project management world. Is this still valid in the Agile and Scrum world where people are preferred over processes and tools? In fact Scrum is disciplined and uses a lot of metrics, so you might like this newly proposed Scrum Adherence Index.
Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
Scrum Expert Copyright © 2009-2024 Martinig & Associates