Analysts (not clients) as Your Scrum Product Owner

In a conversation yesterday I was talking with a colleague of mine about the difficulty of doing Scrum in a consulting environment, such as when we are hired to build custom software for our clients. Often times we are on a fixed or firmly entrenched budget (whether our contract is Time and Materials or not) and our clients don't have the time to sit in and fill the role of Product Owner. Nor will that client really want to participate in many of the day-to-day sessions.

In this setting (well, most settings actually) I highly recommend having a talented business analyst on the project. This person's primary job is to gather, refine and prioritize requirements. Their role in RUP and other processes remains largely unchanged. In fact, many of the great tools and techniques learned in RUP and UML translate very well.

On a Scrum project, these analysts should work at least a Sprint ahead of the development team. They meet with clients and get documents approved and signed off on. Then when the development team starts a new Sprint, the analyst fills in the role of Product Owner. They provide hands on reviews of software in progress and help interpret requirements. Sprints start off very effectively because that analyst has documented a use case or user story and may even have some wifreframes sketched out.

It is the analyst's role to get questions answered quickly from the client in order to keep the development team productive.

Their are obvious downsides, of course. The analyst is NOT ultimately the actual Product Owner. There is a difference between what the actual Product Owner will want and what the analyst will specify. I contend that for most software projects the difference is acceptable and their really are no better options without the Product Owner making a larger commitment of their time.