Scrum Agile Project Management

The Implications of Having a Definition of Done on Fixed-priced Contracts

April 29, 2013 1

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.

Turning the Tables in a Scrum Retrospective

April 25, 2013 0

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.

Technical foundations of Distributed Scrum

April 18, 2013 0

Distributing Scrum projects isn’t easy. Agile values encourage face-to-face communication and frequent feedback between team members. But for those who seek the benefits of Agile – frequent releases, less waste, high emphasis on value – on larger, more complex projects, this video presents some technical practices that help retain the spirit of co-location in a distributed environment.

Exploring Technical Debt

April 17, 2013 0

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.

The Agile Atlas

April 15, 2013 0

The Agile Atlas is a web site supported by the Scrum Alliance which is an information resource for Scrum and Agile practitioners. The purpose of this site is to provide an “encyclopedia” of information about Agile and related methods.

Scrum Sprints Duration

April 2, 2013 0

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.