Articles on Scrum and Agile Project Management
The Definition of Done is an agreement between the Scrum team and the product owner on a minimum quality barrier for the product that’s being built. Establishing a minimum quality barrier has much wider implications than just better quality product, although that is one outcome of having a Definition of Done. This article is about the impact of a definition of done on the types of contract that Agile teams work with.
Running continuously sprint retrospectives while keeping the Scrum team awareness during this activity is one of the biggest challenge for ScrumMasters. In this article, Marc Nazarian present an game called “Turn the tables” that should help the ScrumMaster to achieve this objective.
The metaphor of technical debt is widely used in software project management in general and especially Scrum. This article written by Philippe Kruchten, Robert L. Nord and Ipek Ozkaya try to put this concept in perspective, discussing how it has become somewhat diluted lately with its extension to other areas than code or its associations with tools like static code analyzers.
Absent ScrumMaster, poorly defined requirements, inexperienced team, absent product owner, impossible goals. Sometimes things can go wrong even in projects that use an Agile approach like Scrum. The main issues are absent product owner or ScrumMaster, an inexperienced team, poorly defined requirements or impossible goals. In this article, Avelino Ferreira Gomes Filho shares some of his experience as a replacing ScrumMaster in troublesome Scrum projects.
Whether you follow a Agile framework like Scrum with its planning poker or a traditional project management approach, the estimation activity is always difficult to perform productively and consistently on the long term.
A prevailing belief among Agile and Scrum proponents is that “a great deal of explicit risk management becomes unnecessary when a software development project uses an agile approach.” In my experience, this is a false and dangerous assumption. Project risk is a hungry leopard ready to devour the unprepared. Fleet-footed agilists and die-hard waterfallists alike.
The main goal of a sprint review in Scrum is to receive feedback on the product that the team has built in the last sprint. How do you do when the product is created by many different teams and there multiple stakeholders who are involved in the Scrum project? In this article, Stephan Kraus explains how to scale the sprint review in Scrum using the fair concept.
Scrum Expert Copyright © 2009-2026 Martinig & Associates