Articles, Blog Posts, Books and Quotes on Agile Project Management
Modern Agile software development approaches like Scrum recommend a “just in time” vision of application development that tends to make people focus only on the activities that are directly useful for the current sprint. How can you include an activity with a long-term perspective like enterprise software architecture in the iterative process of Scrum?
In a Scrum context, the definition of a “spike” is “a story or task aimed at answering a question or gathering information, rather than at producing shippable product.” In this article, Bill Ambrosini discusses how to manage them and when to use this activity.
Backlog refinement is an important part of the Scrum team activity as it allows to gain a shared understanding of the work flow. Behavior-Driven Development (BDD) is a technique that use a business language to define acceptance testing (test cases) of requirements. In this article, Zia Malik explains how teams can use BDD to support product backlog refinement.
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.
Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.
Scrum Expert Copyright © 2009-2024 Martinig & Associates