Posts

The Velocity Chart records how many story points are completed in each iteration sprint. This is an important chart to have, and I recommend it to all my clients. As the team creates user stories, they are added to the backlog. At some point, those stories need to move into the current sprint. But how many stories should we move into the sprint? We won’t know until we’ve done some basic estimations to get an idea of how many we should pull from the top of the backlog. ...

The Velocity Chart records how many story points are completed during each iteration sprint. This is an important chart to have, and I recommend it to all my clients. The problem is that many teams use this chart incorrectly. They try to use it to measure how much work the team should aim to complete in the next sprint. Towards the end of the sprint, this can create pressure on the team to work faster to meet that objective (often by secretly compromising on quality). Alternatively, it can cause the team to slow down and stretch their work pace so that their last bit of work aligns with the sprint end date. This way, they avoid closing all their tickets and being left with nothing to report in the daily meeting. ...

Before we had the light-weight agile type of development approaches there were two modes of thinking about how software should be built. The light-weight approach (agile before it was called “agile”) worked well for projects that enjoyed a low cost of change, and solved partially defined problems with informally specified goals. The other perspective was more aligned with “Scientific Management” which worked best for projects that suffered a high cost of change and solved very well-defined problems with extremely specific goals. ...

I’m not particularly fond of the term “sprint”. The word “sprint” often gives the impression that the team needs to prioritize on working as fast as possible. And inadvertently creates pressure to complete every user story before the end of the sprint, sometimes at the expense of quality, or by allowing technical debt to build up. In reality, agile development is more like a marathon, where we maintain a healthy, steady, sustainable pace. It’s not a relay race where teams sprint as fast as they can, trying not to drop the baton at the end of each leg. ...

Agile works well for projects that have: A low cost of change Problems that are discovered along the way. Informally specified goals, that could alter. A more traditional approach might be a better option when: The cost of change is high. The complete set of problems are known up-front. The goals are very specific and fully understood from the start.