Planning a requirements gathering session using Agile

Question

We are planning on introducing Agile into our development process (a shift from the waterfall we've been using so far). We are leaning towards a hybrid model in whcih the requirements gathering session is comprised of a business analyst, subject matter experts, technical person and a user interface person. The plan is to create user stories that the development team can use in their agile process with 1 month sprints.

Has anyone had experience with a hybrid model? How has it worked for you so far?

Answer 1

So far I have had experience with hybrid models only :-) None of the agile projects I have worked on so far implemented any Agile methodology strictly by the book. You needn't either.

The point is, any methodology is just a starting point / a collection of ideas you can use to work out your own process, tailor made to the specific project, team and circumstances.

Start with a process which looks good to you, then see how it works in practice. Keep regular retrospectives at the end of each iteration to assess how things are going, what worked in the last iteration and what didn't, and how could you improve things further. Then implement the most important ideas in the next iteration. In other words, develop the development process itself in an agile way :-)

Update: anecdotes about the requirement process

As I write this, I realize you may not got much useful info out of it... but at least it shows you that projects and processes vary a lot.

In one project, we had a fairly strict Scrum process, with a product backlog, although we didn't have a real customer: the product was new, and the prospective users didn't yet know it existed. Also it was a fairly specific and standardized domain where our company had a lot of experience. At the time I was part of the team (this was before the first release) we didn't really have much formal requirements gathering, because much of the key requirements were imposed on us by a standard. On top of that, we had some of our own ideas how to make the product stand out of the crowd.

In another project, we loosely had a Scrum process, but our sponsors and users did not really know about it, so we were struggling quite a bit. The "requirements gathering" was rather informal in that the product was huge and different people / subteams were assigned to different areas, working fairly independent of each other. Each subteam had their own contact(s) to discuss the requirements with, and the contacts were geographically separated - we rarely saw any of them face to face, so most of the communication happened via email, using lengthy Word docs. To top it off, we had a team of domain experts, who were often in wild disagreement with the users regarding the concrete requirements, however they were not very communicative. So the requirement process often consisted of reading lengthy documents containing obscure mathematical stuff, then other lengthy documents containing GUI requirements, then trying to figure out how to bring the two together... then discussing the requirements with the domain expert who briefly announced that it was a piece of sh*t, and we tried to tease some more useful and concrete improvement ideas out of him... then rewriting the requirements doc according to our latest understanding and the expert's comments, and sending it back to our contact person... then repeat from square 1.

In our current project, we again have many users scattered around a large part of the globe. However, at least our IT management is more knowledgeable about SW development and agile processes. We work on a large legacy system, which was in a pretty bad shape a couple of years ago - so maintenance and stabilization is a large part of our day to day work, and new requirements take less than half of our time on average. When we have one, though, we usually have preliminary estimation meetings where we try to come up with a crude estimate on how many person-days this project going to take. Then later our business analyst works out more and more details with the stakeholders, and our team works on filling out the technical details.

Answer 2

One of my colleagues (I work for a company which consults in agile working) has written several blogs about this separation between the requirements gathering and the development process. He describes how this can work very well in practice.

Answer 3

It seems to me if you label business analyst, subject matter experts, technical person and a user interface person as "the product owner" team, you really haven't deviated from "pure" agile.

That said, "pure" agile is somewhat of a misnomer because most agile advocates will tell you that the #1 or #2 selling point is its ability to adapt to the business processes and corporate culture of your existing organization.

The critical success factor might be having that product owner team, and all stakeholders really, invest in participating in some of your dev team's agile processes (showing up for demos, being accessible for questions during the sprint, etc).

Edit:

This quote from Wikipedia documents the very simple role of the Product Owner:

The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.

Scrum isn't meant to enforce processes on how the Product Owner gets their job done. It's only the interface between the Product Owner and the Team (sprint planning and sprint review) that Scrum tries to outline.

Answer 4

The plan is to create user stories that the development team can use in their agile process with 1 month sprints.

Some remarks:

• 1 month Sprints is IMHO too long, especially for an adoption and I prefer to use 2 to 3 weeks Sprints. During an adoption, shorter feedback loops give you the opportunity to inspect and adapt more frequently and since you are experimenting, this is in general appreciated.

• I don't really understand what is so hybrid in your requirements gathering session as long as the goal is not to create the "final" list of fine grained Product Backlog Items in one shot (a backlog has typically a pyramidal structure with fine grained items at the top - for the upcoming iterations - and coarse grained items at the bottom). Having story-writing workshops ahead each iterations is a common practice.

PS: While I respect Péter's opinion, I have a slightly different one. I consider Scrum (we're talking about Scrum, right?) as a minimal and finely balanced framework and recommend to stick as close as possible to doing Scrum by the book. Sure, the goal is not to be Scrum but to deliver working product increments. But unless you have someone experienced with Scrum in the team, you (as organization) are not really qualified¹ to alter the framework (and to understand the impacts) and might not get all benefits. Scrum is flexible, there aren't two similar Scrum implementations. But dropping a part of the framework is not the same as being flexible.

¹ I often introduce the Shu Ha Ri progression model (that roughly means learn - detach - transcend) for agile adoption. From the C2 wiki:

As the beginner starts to learn, Shu gives them structure. It forces them to adhere to the basic principles (...). Since the beginner knows very little, they can only progress by slavishly adhering to these principles (...).

As the beginner gains experience, they naturally will wonder why?, how?, is there something better? Ha... the separation (much softer word than break) is the experimentation done around the principles... first straying only a little and then more and more as these ideas are tried against the reality of the world.

As the experiments of the Ha stage continue, bit by bit, the successes are incorporated into daily practice... we look for opportunities and use the patterns we have learned and tried out that closely fit those opportunities. This Ha/Ri stage is what makes an art the 'property' of the practitioner rather than the teacher or the community. Eventually, you are able to function freely and wisely.

I'm certainly not saying that one must stay at the Shu phase (the goal is beyond the first level), what I'm saying is that learning new ways of working takes time, don't ignore practice. As Ron Jeffries once said "They're called practices for a reason... You have to have done them. Practice makes perfect."

---

Update: (answering a comment)

One of the decisions we would like to take is the role of each person in the 'Product Owner' team.

Just to be clear: there should be only ONE Product Owner. He can of course work with a team but, still, there should be a single authoritative voice for the team. If I rephrase, there is no Product Owner Team.

For ex: What would the role of a technical person be?

Well, for me the technical person has no role to play in this team (unless he is there to train or support people at writing stories but the ScrumMaster should typically do that). Writing stories means capturing the essence of business oriented features, there is no real need for a technical point of view at this stage. Technical complexity (or even feasibility) will be included later in the estimation.

It seems to me that the end result of the requirements phase would be user stories that the developers will use in the iterations. Will the technical person be estimating the tasks? Traditionally, we've had the programmers estimate their own tasks

People doing the work should estimate the work (you can't expect a team to commit on something if someone else estimate the work for the team). In other words, the team should estimate stories. On top of that, experience shows that 1. collective estimations works better than individual estimation 2. we are better at doing relative estimations. So my recommendation would be to estimate the size and complexity of stories relatively using story points/t-shirt size/unit-less points and to do collective estimation during planning poker sessions. This worked very well every where I used this.

Answer 5

Could we call this, "Building the back log," as that is really what this is, to my mind? The idea is to get those top priority pieces and then work from there. I have seen a few different Agile processes and some worked better than others but the key is how well is the buy-in from those involved in the process.

I'd also agree that 1 month is too long for a sprint. 2 week sprints seem about right to my mind though I have seen slightly longer and shorter sprints that also work. Another question is how big is the team and projects that are being done as stuff that may take years may not be easily done. I say this as someone that survived a project that lasted over a year and many sprints and demos later finally finished the project successfully.

---

I'd likely consider the technical person being the one that has to keep an eye on the big picture and understand what may be reasonable to do and what is unreasonable to do,e.g. having the system read my mind to know what I want done before I wake up in the morning without my having to write out anything other than simply thinking it would be unreasonable. Don't forget that the stories will develop into more cards as the stories are just a high-level view of what the end result is, which usually doesn't cover how easy is it, how much time will it take and a few other aspects.

For the sprints themselves, developers should estimate how long it takes to do various tasks. Determining the priority of stories though isn't part of what the developers do though. The requirements gathering session could also be seen as building a project charter so that there is a timeframe for the project as a whole, objectives and other high-level details that should be stated at the beginning.

Answer 6

Hi Dave,

Even teams who claim to be pure Agile are probably a hybrid to some level. The amount of Agile used usually correlates to the urgency and volatility of a given product or project. The more urgent and undefined, the more you need Agile practices.

I have been helping teams iteratively migrate from waterfall to Agile for the last 10 years. Feel free to contact me if you would like some advice. [email protected]

You can also read more on my approach to moving to Agile in my book "Becoming Agile in an Imperfect World". You can see a review here: http://devblog.petrellyn.com/?p=163

Thanks! Greg