InfoQ readers: There is an incorrect link on InfoQ. If you’re looking for the Rothman article on addressing technical debt, you can find it here. But since you’re here already, why not stay a while and enjoy the view?
This article was written for the ScrumAlliance [3] and featured on the site on 17th July, 2006. There was some significant editing before it was featured [on the ScrummAlliance.org website] so there are differences with the article presented here. The message however remains the same. You can find the original article here.
This article is the orginal unedited version, complete with bad grammar and spelling mistakes!
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
A question that often comes up on Agile projects is; how do I determine when I can release software? For most project teams that are accustom to a defined process (Waterfall, RUP etc) it’s not immediately obvious how transition an Agile project from “Development” to “Production”.
I have put quotes around “Development” and “Production” because, within the Agile world, there is no concept of a “Development” phase nor a “Production” phase.
But regardless of Agile niceties, how do Agile projects go live?
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
Over the last six months, I have been working with a client that is moving from “RUP” to Scrum. It’s unfair to describe their projects as using RUP because in truth they’re more waterfall than RUP. The project teams used RUP nomenclature and artifacts, but still worked within the waterfall lifecycle.
One particular project that I help convert had an interesting set of circumstances that put the Product Owner/Customer in a very difficult situation.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Estimating, Organisation Change, Project Management, Scrum
I’ve recently been coaching a team that has taken particularly well to Scrum. After a few iterations the project team quickly settled down into a regular rhythm of producing software. The ScrumMaster (Ken) dutifully recorded the teams Velocity [the number of Story Points completed per iteration], in addition to some financial metrics. This included the cost of each iteration (also known as the burn rate).
At some point the Ken decided to calculate the cost of each story point. This is a brief description of what he did and the results.
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
I’ve long struggled with the concept of Story Points and how to effectively communicate this to clients. It’s never been a natural concept for me, and most explanations of Story Points are half baked. Explanations such as “Story Points are relative measure of complexity”; are quickly countered with “What about situations where something is not complicated by takes a long time to build?”
Most Agile practitioners end up trying to cover all bases by defining Story Points as some measure of both size and complexity [3].
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
Recent Comments