Ulf Ackermann Dirk Fritsch

Customized Agile RE Process

Agile Requirements Engineering Procedure Model using the RE Tool Jama.

‘Classic upfront Requirements Engineering before the start of a project costs too much time and money!’ …nowadays, phrases like this reflect most customers’ view of heavy specification documents. An agile approach based on Scrum is praised as the answer to this problem. Especially in bigger IT-projects, with teams distributed around the world, the classic Scrum process using written cards pinned on a board, will soon be obsolete. Dirk Fritsch and Ulf Ackermann demonstrates in this article how to avoid the classic paper shuffling by setting up a cleverly designed structure in the RE-tool ‘Jama’, helping the customer to complete a successful project.

This article illustrates a fresh process model for dealing with agile requirements for a project or requirements manager working in a software development company. The project structure in such companies is often organized based on a methodology that has produced passable results in past projects. Most of the time these are lightweight models based on standards such as PMI ®, PRINCE2 ®, or some sort of V-Model which act as a template. Basically, frameworks which give the customer a good idea of what they can expect for a fixed amount of money. Problems with such models arise when customers don’t know exactly what they want prior to the start of the project and when they want to make improvements as they go along. So, when a software development company acquires a new project for a customer, the customer will in some cases require it to be ‘agile’. It is likely that they will want to be agile when it comes to requirements. This is natural and can be a good thing for the final product - when ‘dealt’ with in the right way. Of course it makes sense to start from the beginning using the tool, but it is important to map out the process before working in a tool. We chose Jama, mainly because of some very useful features such as the review center functionality and custom reporting. The most important feature of such tools is the link feature, which allows for traceability throughout the project.

Scrum or ‘agile’ has been prominent since 2001 ^[1] and almost every software development company has it in their portfolio of project procedure models for dealing with agile project scenarios.

But does Scrum agility really work for larger projects with more than 10 people working in several different locations? Does it work, when the customer is not physically near to, or even not part of the project team? How do you document bigger systems, or how do you transform classic specification documents to use an agile approach? How do you document the software that has evolved through more than 10 sprint cycles, where parts of the solution have already been amended twice? To answer these questions we need a well-documented process model which combines classical best practice from established methodologies with the ability to constantly refine the system.

The process model illustrated in this article can answer these questions and has worked successfully for projects. It also includes improvements derived from experience on those projects.

The authors are assuming that readers have a basic understanding of Scrum principles including meetings and roles as well as the concepts underpinning different classic waterfall development models.

We consider this model to be a good way of handling agile fixed priced projects, as well as those based on time and materials. This article starts from scratch, detailing the tasks required to set up a structure for a successful agile project. Based on the results of the setup procedure, we will show how to start being effective in sprint iterations.

1. How to set up the starting point structure

To tackle the fact that most customers want to know what they are getting for their money, a good procedure model must offer some sort of safety mechanism. That’s where we employ a product breakdown structure (PBS); this product-based planning is common practice in the PRINCE2®, methodology ^[2].

A PBS is hierarchical – and can be considered a mind map with the software system in the middle. Using this structure we describe the planned layout of the software system. This is the hardest but most important part of the whole process model, creating the foundations on which to structure user stories, epics and change requests. When your customer chooses a fixed price contract, the PBS will act as the boundary for defining change requests. Everything that cannot be sorted into the existing PBS will need a new structure element to be added and can thus be regarded as a change request.

Since the process model is meant to be used from the start of a project, multiple starting scenarios should be considered. In this article we will focus on a new system to be developed. So either some sort of pre-project documentation with some kind of business requirements already exist, or they do not.

In the first scenario, the question might be asked about how to transition from a classic requirements specification document or a customer specification sheet to an agile document. This is where the PBS is very useful, since it can be used as a target for a mapping process from the pre-project documentation.

To keep it simple, every headline of the specification sheet will form a structure element in the PBS and every requirement or set of requirements will be an Epic sorted under the structure element (see figure 1). It’s important to keep the link from the classic requirements to the Epics to start building up helpful traceability. In Jama ^[3] you just use the relationship feature to create traceability. The relationship feature will act like a pointer from some element to another, in this case link or ‘point’ downstream from ‘Classic’ to Epic.

If you start from scratch it is even easier – all you have to do is build your own PBS based on something pre-existing. If you customize standard software it’s a good idea to use the structure of the vendor. If you are building something completely new, then start by breaking down an old project with similarities.

As the end result you have a customized PBS as a base. We highly recommend investing in this work prior to signing a contract with a customer and using the PBS as part of the contract, thereby minimizing the risk of out of scope requirements arising within the project. As a rule of thumb, a good PBS can still be printed on an A4 sheet of paper.

2. How to bring the PBS to life

Imagining the PBS as a trunk and bare branches of a tree, you then need to bring it to life. Continuing with the tree analogy - populate it with fresh green leaves. As we are doing Scrum, we will start by writing Epics. They are as described above larger functional descriptions that can be detailed by user stories. For our model we will use Epics mainly to prioritize and to give the customer an idea of what kind of software system he will end up with.

Our Epics will be put into the PBS to bring our tree to life. This process - think of watering the tree - also tests the PBS. The test run is simple, as every leaf should contain at least one Epic with 3-10 sentences each. These should read from a customer point of view. For example ‘As a customer I want, because…’ and then go into more detail, always giving a reason. If you forget the reason, a developer will always come back and ask – with a good reason, you encourage creative solutions.

If you start with existing documents you will first need to import those documents into an RE tool like Jama. To have them available as a reference items for traceability you can import them as Word or Excel documents. Prior to the import, those documents usually need to be formatted to successfully pass the process. Basically headings will be formatted into a title of a requirement, and the following paragraph will be included in the requirements description details.

Heading levels will then form the hierarchy, so the structure of the word indention is transferred into Jama. This preparation needs to be planned, usually taking about an hour for every 100 pages in a document.

Once any existing documents have been imported into the tool (see figure 2), you can structure your new project with folders based on the headings (remember figure 1) from the reference. Creating the folders is a creative process in which you can transpose requirements from a classic to an agile style. In our experience it is vital that this is done in a team including people from both business and technical backgrounds.

In summary, the classic base documents are now available within the tool, taking the form of items as well as a structure of folders. In this scenario a copy of the very same folder structure is then used as grouping for your new epics to be derived. It’s recommended that this folder-copy is also placed directly under the root node as a set of epic type items next to the base elements. To ensure that all of the base documentation has been processed, link each base element to the new epics.

This is all you need to do to convert the documents into the new agile world. Just remember to be flexible: don’t include the old specification as part of your contract – as customers will love to revert back to it. Instead use it just to show the customer that the project is pointing in the exact direction they want it to go and leave it as a reference to the old world.

So at this point almost everything needed to start the real project work is there. Based on previous experience you can then estimate a price for the product to be developed based on the Epics. Estimation based on Epic-blocks is always better than estimating single items as you can keep track of synergy effects.

3. How to prioritize Epics

Once you have a signed contract, the next thing on the list is to start capitalizing on your structured Epics. This is where the real customer interaction starts. The customer will receive a list of all epics and can then prioritize them. This is also done as a direct export from Jama: we simply create a round trip report via excel and let the customer switch some cells before we re-import. A simple 1, 2, 3 priority is enough, where 1 represents the most important. However, it is helpful to introduce a rule that only 30% of Epics can be priority 1, 50% priority 2 and 20% priority 3. This helps to avoid a disproportionate number of high priorities. By doing this the customer can communicate what is most important to them at the moment - it’s a good idea to help with this using your product experience. We have experienced, that this procedure provides the customer with a powerful steering wheel to guide the project at the start of each sprint.

4. Start filling the backlog with stories

Now, with the order of epics clarified, you can start filling the backlog with user stories. It is vital that you do this upfront with the customer; otherwise your specification team will be working behind your development team. (Your specification team needs to be at least 2 weeks ahead of your development team before starting.) Start with the highest priority and stop once you are halfway through the priority 2 epics. Nothing needs to be perfect at this time - just don’t forget to link from Epic to User Story to keep building up your traceability. Jama provides a very neat feature, the coverage explorer (figure 3), where you can see the coverage of epics linked to user stories.

Now you have the PBS as a structure. Epics ranked by priority show the direction and user stories derived from the epics show the details.

Let us illustrate how this is structured in the Jama toolset.

Let’s take a scenario with existing documentation where the structure/traceability looks like this:

• Customer Document (old) → Epics → User Stories → Test Cases → Defects

In the Jama tool it should look like this:

5. Process overview

Now that the structure and tool-setup is done, we will present the overview of the process model with the most important checkpoints.

Our process (see figure 5, letters in brackets inside the functions will be referenced within the text) is based on our best project experiences and will be described in brief here.

Since the process is a round trip, it shows the nature of one ‘Sprint’ iteration. The duration which we have found to work best for us (with a team of > 10 members) is 3 weeks. 2 weeks turned out to be too short, since the necessary meetings are time consuming and a real work spirit cannot evolve in such a short time frame. The notation used in the simplified procedure model diagram is BPMN 2.0.

5.1 Prioritization and writing stories

First of all, after some preparation for every sprint, epics are Re-Prioritized [A], so the customer can take the steering wheel at the beginning but not within the sprint itself. (Changing direction on epics, or even worse the stories, is the number one thing to avoid within a sprint.)

Then of course constant input regarding detailing requirements is a must [B], as well as writing user stories based on epics. This is where the classic requirements engineering skills of the product owner come into play. Keep in mind that your stories must be well-defined and include acceptance criteria – otherwise your development team will have a very hard time.

The Review Center from Jama (see figure 6) is a great help here, as it allows you to give the customer a current snapshot which can be reviewed and commented on by multiple reviewers simultaneously. It’s also one answer to the question of how to bring the customer closer to the Scrum team.

5.2 Refining and Development

The product owner has to give the Scrum master the signal to initiate refinement meetings [C] once user stories have reached a certain level of detail. Within these meetings the stories are refined with the team. If there are no more questions about a story from the development point of view, then this story is sufficiently well refined. ‘Well refined’ means that the team has also estimated the story’s complexity based on a comparison story. It’s good practice to have one comparison story for each complexity level to avoid over specifying. At the end of the day all ‘well refined’ stories must be considered for the next sprint. This process must be performed together with the architect of the solution, to select stories that make sense together. They also must not exceed the maximum amount of story points for a sprint. We used the release feature of Jama to structure the different sprints. In refinement meetings the batch work in list views was a great help to add details and story points without constantly jumping around on the screen.

The number of story points for a sprint will become tuned as time goes on. However, if you are in a fixed price contract situation, you must define the maximum number of story points for the sprint, instead of arriving at this value via Scrum techniques. This should be done based on a calculation that takes into account the average ‘value’ per epic, considering your total number of epics.

Once you have the commitment of the team [D], you know which stories can be delivered in a sprint - you will then need to have the customer agree this commitment. This can be generated in Microsoft Word format using the Jama custom reporting engine. The customer has the right to change it once, but since it’s based on his prioritization of epics this should not happen. If it happens, review your process of generating user stories and start interacting more with your customer. This also works well in phone and remote meetings.

Once the commitment is official and the customer has signed it, the team can start developing [E]. This is where the Jama/JIRA interface comes into play. All User stories from Jama will be synchronised (based on the status change to ‘ready for sprint’) to JIRA, where the developers can define technical tasks for each story and track progress on a virtual Scrum board in Jama (called JIRA agile) ^[4]. The board is extremely handy for distributed teams and due to the synchronisation, the requirements engineer / product owner can also see progress and even answer questions using the RE-Tool.

5.3 Review and Approval

Once the stories are done (remember to have a good definition of done), they will be evaluated within the internal sprint review [F], so the development team will show the product owners the result before the customer. This acts as a shield for unwanted surprises (and as a source for new Dilbert cartoons!).

A retrospective meeting is desirable to refine details of the project, and should be held at the end of each sprint by a neutral Scrum master.

To keep the product well documented you should also continue to write a feature log. The feature log describes all real ‘features’ of the product, whereas a story will just say what was done in a sprint and why. This is extremely handy for creating user documentation afterwards. So to get the big picture of what the software can do, no one has to crawl through hundreds of user stories to get a rough idea of its state. Writing the feature log is done directly into Jama [G]. You could also use the link function to link from user stories to finished features. If you let the customer sign this feature log at the end of each sprint, it will be a much better base for defining bug reports than using user stories as a base.

Then for the final sprint, the customer is given a ‘Sprint Approval’ excel report which contains all of the stories. The customer can then confirm that these stories are completed to their satisfaction! This should also be checked in a meeting with the customer and physically signed, so you can keep track of which stories are officially in the product and which are not [H].

Then of course the whole process repeats over and over, until the customer is happy.

6. The benefits

We illustrated a custom use of Scrum with a high percentage of tool-based interaction and lots of exports on paper to be signed. The paperwork is necessary to document the progress of the project, as you would in a classic procedure model with a huge specification document. So the work of a requirements engineer is spread out over the whole project, instead of doing most of the work prior to development.

In our experience this process model has worked best when we presented it via BPMN 2.0 in an on-site session, so the customer understands their responsibilities from the beginning. Some may say the process is not pure Scrum because the customer is not directly part of the team. We see this as an advantage for both the service provider and the customer, since it provides a more stable planning base. More importantly it provides a more streamlined Scrum aiming for a predefined goal – it is possible to add some neat things for the customer’s satisfaction, but it is not possible to break out and do something completely out of scope. This perfectly accounts for the fact that every customer has a goal in mind, but tends to add more details on the way to the goal, rather than knowing everything upfront.

The customer is also highly involved in writing user stories through the extensive use of the review center functionality in Jama. This is true even if they are not able to be physically sitting next to you. A team or even Scrum of Scrum teams can work from remote locations, since they use virtual JIRA boards due to the Jama/JIRA interface instead of transferring stories by hand to an actual physical board.

To come back to the initial questions:

• Does this Scrum agility really work for larger projects with more than 10 people working across several different locations?
  In our experience it does work. This is not just because of using the web-based tool Jama; the most important fact is that you visualize your approach and have your customer understand it. This works in conjunction with having a scrum master who can reiterate things when needed. The toolset then just aids your process.

• Does it work, when the customer is not physically near to, or even not part of the project team?
  The review center gives the customer access to the tool. This not only provides them with the latest information but gives them the feeling of being part of your team.

• How do you document bigger systems, or how do you translate classic specification documents to use an agile approach?
  A proven approach to the translation process of classic documents was described. You are able to document software systems of any size based on a PBS structure.

• How do you document the software that has evolved through more than 10 sprint cycles and where parts of the solution have already been amended twice?
  To document evolving systems, writing a feature model and adding to it in each sprint has worked best.

A downside to our approach is that it involves a lot of administration to produce each of the export documents, which is a time consuming task. Another issue to deal with is the fact that a customer must have the right to change a sprint commitment if it doesn’t fit his needs for the current sprint. Usually your sprint development team has already started the development if this happens. One way that we found to tackle this issue was to start developing the stories linked to high priority tasks first. Our theory is that high priority tasks can be articulated very clearly and will be included in the product sooner or later anyway, so you won’t need to dump your existing development work.

The main benefit is that you can take the ideas outlined here and incorporate them into your own custom RE-Process. Creating happy customers by letting them be agile with requirements within a well-defined boundary.

References

• [1] The Scrum Guide, Ken Schwaber & Jeff Sutherland; https://www.scrum.org/Scrum-Guide
• [2] Wikipedia Arcticle about Product Based Planning; http://en.wikipedia.org/wiki/Product-based_planning
• [3] Jama product information; http://www.jamasoftware.com/solution
• [4] JIRA agile product information; https://www.atlassian.com/en/software/jira/agile