Regardless of how you manage your software development, at the end of the day it's really all about communication. Communications in a software development project are typically chain-like. The User tells an analyst what they want, analyst translates into analyst-speak and writes this down. This is passed to a system architect who re-interprets the document, and creates a design and a document in architect-speak. The requirements and design are then passed to the developers, who re-interpret both and then implement their understanding of what the user wants in code. This sounds well and good, but it only works if extreme care is taken at every link in the chain. Recall the game of "telephone"...

Although typically a game for grade school kids, "telephone" showed us early on that communication chains are fraught with peril. If the message started out "Today's forecast is calls for snow", at the end of the circle, it would be "Tookeys feet are slow". This was quite funny back then, but we seem to lose this valuable lession as we age. We see this same thing can happen with software requirements - and then it's not quite as funny. (Besides - how can I code slow feet?)

Agile seeks to reduce the bulk of the "traditional chain" by having the team (developers + designer + analyst) collaborate with the end users to create a workable shared vision of the product. The key thing here is ensuring that the collaboration actually occurs. Too often the users are busy doing their "real" jobs, and the team is "pretty sure" they know what to build. But if the collaboration is short changed, then one of the major benefits of agile falls out.

Recently our team finished just such a sprint. The client was very busy, and the team was pretty sure we knew what they needed. During the sprint review with the client, some of the functions we had coded missed the mark. When we went back and reviewed the requirements, what we had developed seemed a reasonable solution. The lack of collaboration had bit us. We did not have the shared vision - just a requirements document that was written by a different consultant.

Luckily we are doing two-week sprints, so we were only a little off course, and should have no trouble getting things back on track. To address this issue, we have decided to adapt our Sprint Planning meeting to include a more formal review of our understanding of what each user story entails. Prior to this meeting the team will review the top priority user stories, the associated requirements, and the existing application, and determine what they believe the "shared vision" should be. Then at the meeting we will review this with the users and they can correct or add anything we had missed.  I'll let you know how this works out.