Rose had some great comments on dealing with client changes. A well defined agile process will accommodate this while creating true transparency in the process for the clients. In the end you are able to capture more revenue because the client clearly sees the changes that are outside the originally scope. Client input gets entered into a document called a TA22 (this is done during the 210 stage). The client signes off on it and is clearly aware of the direction for development. Significant changes after the TA22 are done through a CR and may cause a delay in the deliver, add extra cost or both, but the transparency the process itself creates makes these changes and delay’s the client’s responsibility. At the end of the day everyone is happy.

Internally to the sprint if work was not finished or work was added back to the backlog because it needed re-work we tackled this in 2 ways. If it was small enough to consume quickly we’d tackle it before the next sprint began – This was possible because we defined a 1 week break between sprints. If it was larger it was added to future sprints via the backlog grooming prcess.

Clients being clients, I’d be interested to know how the team managed the inevitable change requests. Were they incorporated into the current sprint or added to future effort?

Great job on this!

This post was mentioned on Twitter by KSCollective: RT @Razorfish: An agile approach to website development in automotive: new post from @Razorfish @Headlight blog http://tinyurl.com/ylsg7sj...