Like many passenger railway services around the globe, the NS is continuously and actively engaged in improving its passenger-related performance. It has a punctuality rating of nearly 95%, and three quarters of its customers award a mark 7 or better (out of 10) for general customer satisfaction.
Business to employee technology plays an important part in ensuring a good customer experience. At NS, over 10,000 front-line employees access a device called the Railpocket to help them deliver services, such as ticket validation and trip or station updates. However, in 2014, after assessing the device’s technical limitations and an out-of-date operating system, NS launched a project to replace the Railpocket with customized mobile apps that run on company smartphones operating the Android mobile operating system. Our goal is to terminate the Railpocket device by summer 2016.
NS piloted the initiative in the first half of 2014 and we started with the implementation of the total project in the second half of that same year. At the end of 2014, MyContacts, a NS contacts tool, was released to employees. Currently, the second app, MyShift, is in a trial phase with 50 ambassadors.
The MyTrip App, is one of the apps currently in development.
Understanding Requirements
With over 10,000 rail employees, working in shifts, gathering the right requirements for the new Railpocket can become a time consuming and tedious job. Therefore we decided to use an already existing group of 50 ambassadors to represent the needs of the 10,000 front-line rail employees for our business-to-employee mobile application project. But even getting these 50 people together at the same time and getting them to agree on the requirements was a pain staking challenge. For example, the information that a conductor may need to know varies from that of a customer service representative or a quality assurance agent – and yet, they are all front-line employees who require timely access to accurate information.
So, here we have an IT project, in the relatively new field of business-to-employee app development, with a fixed deadline, over 10,000 end users represented by 50 ambassadors and some 40 individual stakeholders within NS. This project had all the characteristics of an agile endeavor, therefore it was decided that this project should be executed using the Scrum framework.
We have put a multi-disciplinary project team together made up of an insourced (on premise) Scrum development team of three developers, two testers and a part-time architect, led by a Scrum master, and a NS product owner and requirements analyst to prepare requirements and specifications. The development team needs to function as a App Development Factory where, based on business priority, work orders are placed.
Value Working Software over Comprehensive Documentation
Railway companies, like postal services and power networks, are supported by capital-intensive public infrastructures. Within these environments, a large portion of the IT budget is usually allocated to maintain mission-critical systems rather than developing new software. To ensure that new software will have a product life of 10 or more years and will keep on working, good documentation is not only necessary, but critical.
The App Development Factory team wanted to use user stories. They felt that, since the Scrum framework was to be used on the project, user stories are the right practice. They wanted just-enough information to do agile development; after all, their goal is to deliver good working software in timely sprints. The NS on the other hand, does not only need to develop the new system but also has to understand it over time, work with it, change it, maintain it and eventually even replace it. Since outsourced agencies are typically not tasked with maintaining new software, they tend to focus only on what is needed to develop the software and not look at the complete lifecycle of the software and ensure that documentation is available to support the product.
In our opinion user stories were not a viable option for this project, as they provided too little information with too little context. However, the way that NS was presenting use cases wasn’t working either. We were presenting use cases as a whole, rather than as specific scenarios. A change was needed.
Use-Case 2.0 Makes the Connection
Since 2012, we’ve been struggling within NS with the question how to get from high level system requirements (features/epics) to the right level of specification that enables agile development. We found that, when breaking up features into smaller stories without placing them in context, it is very easy to get ´lost´ in the abundance of individual stories and it becomes very difficult to determine whether you’re complete. The more stories you produce, the more this uncertainty grows and becomes a burden on the development team which leads to lower efficiency.
In 2013 I first heard of Use Case 2.0. at a conference on the topic, organized by Ivar Jacobson International, in conjunction with its in-country partner DiVetro. To learn more about Use Case 2.0. we ran a ½ day workshop at NS to introduce the practice.
Since our current way of working was based on Use Cases and Use Case 2.0. still is Use Cases but adapted to fit seamlessly within an agile way of working, the change needed seemed relatively small to me and the promises were good. So in September 2014, a few months after the workshop, I asked DiVetro to help us implement Use Case 2.0. into our way of working on the Railpocket project.
Introducing Use-Case 2.0 enabled NS to be as lightweight as possible by focusing on essentials and zooming in for more details when necessary. Use cases are “sliced up” to provide stories or scenarios for agile iterative development.
The Use-Case 2.0 Essentials Practice starts by finding actors and use cases, and selecting and prioritizing the parts (slices) of the use cases to be developed.
The use-case diagram depicts the basic functionality of the “My Shift” App. The My Shift app contains information about an upcoming work shift including the signing in or signing out and the receiving and consulting of the planned week.
A use-case slice is one or more scenarios selected from a use case to form a work item that is of clear value to the customer. Seems straight forward enough doesn’t it? Well, it wasn’t…
Slicing it up!
We started by creating epic stories from features by looking at the described functional requirement from the users perspective and adding a definition of done and acceptance criteria. Mostly each feature lead to one epic story. Sometimes however, looking from different user perspectives, more Epics were created from a feature. The Epics were prioritized with the business and added to the project’s product backlog. Thus by taking the Epic stories as starting point, we could focus on what was really needed and why it was needed. This helped the development team to focus on business value more than with individual, MoSCoW prioritized features.
From the epic stories, use cases were derived and an initial use case model was created. The epic stories and the definition of done then helped us to fill in the basic path of the use case and to identify alternative paths for the use case which had to be developed in the upcoming sprint.
The next step is to take a single flow through the use case (a story) which becomes a slice of the use case. The first slice for every use case usually is the basic path, or a part of the basic path since the basic path usually holds the most value for the business.
A use case slice describes a part of the use case narrative and the accompanying test cases which are to be executed to determine whether the slice delivers the business value it promises.
Thus you build the system and the documentation in slices, since you only build and document the slices which have to be built in the upcoming sprint. So no large, error prone, completely written out use cases upfront but a lean use case model which at all times depicts exactly what is created and only that. All this was done by the NS Product Owner in collaboration with an experienced Use Case 2.0 analyst.
The above Use-Case slices diagram demonstrates how the use-case was broken up into different scenarios. This use case was sliced up into scenarios such as retrieving (from back office) and presenting the planned shift, signing in for a shift, signing out for a shift, etc…
During a pilot period of a couple of weeks we then introduced Use Case 2.0 to the App Development Factory team for the MyContacts app, as our way to drive development in the project. All the development team members had experience in working with agile development using user stories. Furthermore concepts like use cases and UML were also known to them. Therefore we decided to just go for it and implement use case 2.0. as the teams way of working without prior training and to let the team learn how it works as we go along and actively involve all team members. Since the experienced Use Case 2.0 analyst was part of the team, he could coach the team on the job. Where we before based the sprint planning solely on the Epic Stories in the product backlog (which were way too large for a sprint), we now started by introducing the Use Case slices to the team and gave them Use Cases with only relevant slices in them as input for the sprint. The slices were added to the sprint backlog as work to be done.
During the first Use Case 2.0. poker session within the team, the experienced analyst explained the principles of use case 2.0. and the first slices were discussed with the development team as input for the sprint. During this session, the development team acknowledged that the slices could be used as user stories and seemed of the right size. The development team explicitly expressed that being able to see the individual slices/stories in a bigger context (use case model/epic stories) really helped to better understand the slices. Using the principle of learning-on-the-job, the experienced Use Case 2.0 analyst guided the team into using Use Case 2.0. It took some sprints and some discussion to really get the right level of detail in the slices for the team to implement within a sprint. We discovered that we should not only look at the functionality but also at the technology that was involved and the test effort needed to determine how we should slice the Use Cases. This all influences the amount of work involved in implementing the slices and thus in how large a slice can be. Now we could add slices of the right size and level of detail to our Use Cases and fill the sprint backlog with them. Still, after discussing a slice, we sometimes had to further slice-up the slices to get it right.
What did we learn?
The development team is enthusiastic about the new way of working. With use case slices the development team gets what they want (small enough stories, delivered just in time, to work effectively in sprints) and we can still see the big picture since every slice is added to a use case, thereby delivering functional documentation with the software which reflects exactly what is built at all times.
Slicing up a use case however isn’t as easy as it sounds. You can’t just chop away; the slices need to make sense, have value and need to be of the proper size to ‘fit’ in a sprint. Key to effectively slicing up a use case are: scope of the slice, the goal (value) of the slice and an global idea of the effort needed to implement the slice. This is something that can only be learned through experience, and with the right level of discussion and team work, where coaching is helpful. The coach can challenge the analyst on defined slices and help to find ways to improve them and defining the right level of detail. Being used to specifying a Use Case with one level of detail it was a eye-opener that using Use Case 2.0 you can define each individual slice with the level of detail needed. Furthermore it is essential to only detail the requirements of the slice which is ‘in the sprint’ to prevent inconsistencies between requirements and code and to help the team to focus on what is needed right now. It also helps to prevent irrelevant questions.
Since we build the apps incrementally and shipped the apps to the ambassadors early, we get feedback early and we got a lot!. Here Use Case 2.0 helps us to ensure that we have the right discussions at the right time by enabling us to relate the feedback to the epic stories and focus on the current slice and the goal of the related use case/epic story. Only relevant feedback to slices currently being developed is included in the sprint. Relevant feedback that leads to potential new slices can be ‘parked’ to be discussed in later sprints. Also since we have slices that have ‘user value’ we are able to faster release relevant functionality to users. This helps to keep them and our stakeholders involved and satisfied.
Use-cases slices help us bridging the gap between the NS business and development teams by providing scenarios that the development team can use to develop iteratively and the business can still understand. As our NS Product Owner stated: “Now that we use Use Case 2.0, I can actually choose which stories to implement within a sprint to give the business what they need at that moment”. We now use this method as the standard way of working for requirements engineering on all new projects within NS when working with agile development of custom software.
At NS, before the introduction of Use-Case 2.0, our analysts and development teams worked with user stories that had no direct relationship with the use case. The disadvantage of this method was that it did not keep the specification (UC narrative) in line with the actual status of the software. Now using Use Case 2.0 our documentation is better because it in line with what is being delivered and this helps to support users. Also since use cases are now specified and developed iteratively, we take advantage of the feedback of business and users and changing insights. This way we can avoid putting effort in detailing slices that aren’t needed by the business after all, thus reducing waste!
By using Use Case 2.0. we feel that we can now better support Agile projects, by supplying development teams with the right amount of work at the right time and at the same time delivering more value to our business faster and keeping our specification on track with realization.
About the author
Jordi Reineman is manager of the department Analysis and Design at Dutch Railways (NS) and responsible for the way of working regarding requirements engineering within the transportation IT department of NS. Jordi has worked in IT for more than 15 years, mainly in large custom software development projects, and with a focus on requirements engineering. Jordi is also board member of the Dutch Requirements Engineering and Management event, which is held annually in the Netherlands.