Scrum Agile Project Management

Agile Planning with User Stories

January 30, 2014 0

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.

Dropping Scrum for Kanban

January 23, 2014 0

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.

Getting Value Out of Agile Retrospectives

January 20, 2014 0

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.

Use Technical Debt to Your Advantage

January 16, 2014 0

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?

Scrum Adherence Index

January 14, 2014 0

“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.

User Stories Considered Harmful

January 7, 2014 0

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.