I’m working with a new customer of ours, helping them with the requirements for an application that they will be building in-house. This customer has decided to give Scrum a try, so I’m also helping this project team make that transition as well.

This customer had originally decided that they were going to buy a solution, but after vendor evaluations decided that none of the vendors had a solution that met their needs. Thus, they made the change over to building the solution.

There were some existing requirements that had been documented before the vendor evaluation, but they were very high level, and not complete nor at the right level of detail for the developers to build a solution. Hence, we had quite a bit of analysis to do in order to ensure we had requirements for the developers to work from.

The challenge that the team faced was that all team members were ready to go. In our first sprint planning meeting, I had no troubles figuring out what the analysts needed to do, but the developers just looked at us and asked what should they work on? This put us in a bind, we needed to do some work to create the product backlog before the developers could truly get started. This was going to take us a few weeks to develop at least a sprint’s worth of requirements…yet there development sat…waiting.

Of course, there were a few things from an architectural perspective that development could work on, and they did do those things. However, the developers really needed the first of the requirements so they could get started on building features.

We worked as fast as we could, understanding the problems the project was designed to solve, developing a list of features to solve those problems, and getting those features prioritized. From the prioritized list, we could write our requirements (we are using user stories) for the first handful of features, just enough to allow development to get started. Even thought it took us a few weeks to get there, development now has enough to really go on and is getting started working on the basics of the application.

As I think about this situation, I’m working with my customer to put some basic processes in place so that the next project that decides to use Scrum will not face the same waiting period for development that this team experienced. I am well aware of techniques such as user story sessions, where we get the whole team together and start to write user stories. The challenge with sessions like those is that the stories tend to be all over the place, and it can be difficult to know if the stories are right ones and if they are complete.

I am not advocating that we take a waterfall approach to documenting all of the requirements before the sprints can start, but I am suggesting that by doing a few activities first can help the analysts get organized and working in the same prioritized order that the development team is working in.

First thing I would recommend is getting a Business Objectives Model built. This will help the entire team understand what problems the project is trying to solve, and how you will know when the problem has been solved. Use this model throughout your project to ensure that you are working towards those objectives. If features/requirements come up that are not covered by the Business Objectives Model, explore why? Is it scope creep? Or do they help solve a problem that was overlooked when the model was created?

Create a Feature Tree. This can be done fairly quickly and easily. Have your subject matter experts brainstorm about the features that are needed. I like to start with sticky notes, and then put into an electronic form later on. Once you have your features, you can prioritize them. Use your Business Objectives Model to help you with your prioritization efforts. This list of prioritized features becomes the start of your Product Backlog. The features as like epic user stories, they are placeholders until the user stories can be written.

Now that you have your prioritized list of features, you have your priority on where to get started with the rest of your analysis. If you need to write some requirements for your development team to get started, hopefully that should be easy enough to do and buy you some time.

If you have more time before development needs to get started, I like to get started on the process flows, both current state and future state. I try to work in the same order that the features are prioritized in, so I can continually work to build out the user stories.

As requirements/user stories are written, they can either replace the features in the product backlog, or be added to that list of features. I like to start with adding my user stories, using the features as “headings”. I can always move user stories around in the future if I need to, but using the features gives me a quick way to group my user stories.