User stories, use cases or requirements? A case of trust, responsibility and collaboration?

What is the exact difference between user stories, use cases or requirements? They all have the same goal: capture the needs of the business so they can be translated into a working software application. But there are differences in how the same goal is achieved.

Requirements

Requirements tend to be very formal, text-driven and structured (using categories, sub requirements f.i.). They have to be unambiguous, 100% correct and complete. They also should be measurable and testable in the way that you should be able to verify how far the delivered software fulfills the requirements.

Use Cases

Use cases are also formal, text-driven, structured, complete and 100% correct. Use case diagrams deliver additional information on the roles that interact with the use cases and the system boundaries. Use cases are user oriented. They describe the interaction of the user and the system. Although I never really grasped the enormous use of use case diagram, that are very static and mainly focus on relationships between users and use cases and include, extend or generalization patterns.

User stories

User stories however focus on the value they have for the user. They are less formal and are intended on stimulating open conversations: as a <user> I want <something> so that <benefit,value>). Conversations should be conducted between all participants in the project, not only between business and product owner/analyst as in traditional projects. Also allow them to continue during the whole life-cycle of the project. Completeness is not that important from the beginning: you do not need to specify all details upfront. You do what needs to be done at the right moment, just-in-time. In the end you might end up with a fully documented user story but the actual process of holding conversations with everybody at any time during the project life-cycle is key.  Some agile teams do not write out all details. However, keep in mind that there isn’t yet a device available for capturing these details from the product owner’s head into a readable format.

Upfront

Both requirements and use cases are often used in fixed price project where all the needs of the business are captured in a pile of documents upfront. This pile forms the basis for the negotiation between the business and IT (internal department or external supplier), so of course it has to be complete and correct. But you cannot expect from business or IT to know all the questions & answers upfront: new questions arise and answers change during the project. If however, you take this upfront approach, you end up developing all features, whether they are still needed or not, or are not accurate anymore. Or you end up with endless and frustrating discussions between business and IT. Or even with an application that is not being used by the business, or for the worse you will meet in court.

Gradual insight

Agile methodologies embrace the principle of change. They accept that gradual insight is the driving factor, not only in software development. So agile adopters start developing the “must have” features (MVP, the Most Viable Product), show them to the business them and let the business test as soon as possible. The feedback from these business tests than drives the next iteration: some features will get a higher priority, other are not that critical anymore and even features are changed. Agile focuses on a product that will be used by the business since they are now in the driving seat.

Trust and responsibility

In order to do so, you have to build trust between business and IT. This asks for a major shift in the way you approach your project. It might seem sometimes scary for the business letting the development team estimate all user stories. Or for IT to allow the business to change priorities and even their needs, even when developing. But only then you will get buy-in from the whole team and you will get the product you really need. Since after all it is you, the business, that decides whether this user story has enough business value for you to be developed in the next iteration.

An agile approach wants to avoid differences in expectations between all parties. All have to take up their responsibility and report any uncertainty about the user stories as soon as possible, not after the code has been written.

Mental shift

User stories are not agile by definition, it is more the willingness to build up a relationship between IT and business based on trust and openness, where all parties take their responsibilities. Doing so will make everybody happier and in the end we can deliver and use a product we are all proud of.

Hybrid Project Management

Scrum in a formal environment

Last week I assisted the agile cafe at Equalminds. The audience was hybrid in it’s own way: developers, scrum masters, product owners, PM’s, agile coaches, business and functional analysts. An ideal audience to discuss the following topics:

• How do you conduct Agile projects in companies where a more formal project management is being used and Waterfall is applied for most of the projects?
• How can we provide enough formal information about our Scrum project to these decision makers?
• How do we bring together upfront planning and vision with flexibility to change?
• How do we reconcile strong reporting with increased time to market?
• What are the tasks of the PM, SM, PO?
• Are agile and long-term planning mutually exclusive?

Most of the companies want to become more agile, since they fear they will otherwise get extinct. Agile has however sometimes a bad reputation with managers and executives:  (“The DEV team does what they want, there is only short-term planning, they do not behave professionally, I cannot control them as I would like…). This article will hopefully help you to understand that both worlds have equal value for your company.

Phases

A classical Software Development Life cycle consists of roughly 4 phases:

1. Initiation (Planning)
2. Definition (Analysis & Design)
3. Implementation (Development & Testing)
4. Close (Support & Maintenance)

Only the implementation phase is performed in an Agile way. The other 3 phases are tackled in the classical approach.

Organisation

Beside the Agile team for development, we have the Project Board, Project Management, Program Management and Portfolio Management.

Roles

The roles we need during these 4 phases are:

• Portfolio Manager (Product Manager)
• Program Manager
• Project Manager (PM)
• Sponsor
• Stakeholders
• Product Owner (PO)
• Scrum Master (SM)
• DEV team

Roles during SDLC

These roles are not needed during each phase of the project. The SM for instance will only be needed from the end of the definition phase until the beginning of the Closing phase. The DEV team will start a bit later in the project and probably a part of it will assist in the Closing phase as well. The PM will play a minor role during the implementation phase, where the PO plays a major role.

Roles in your organisation

These roles will be part of the different units or teams in your organisation:

SM, PO and PM role for 1 person?

Since a SM, PO and PM will have overlapping tasks, you might assume to assign all these tasks to one physical person. It is much cheaper and there is no knowledge transfer when only 1 person is eprforming all these roles.The PM is responsible for Micro Management (Planning, Risks, Task assignment …) but during the Implementation phase the DEV team chooses what they will implement during the sprint (from a  list prioritized by the PO, also called product backlog). A PO is product oriented, typically a more introvert profile, focused on deleievring the best product for your company,  whereas a PM will not survive if (s)he is being not extrovert. A SM is a facilitator whereas a PM is more authoritarian. To combine all these skills into one profile is hard. To find somebody who is at the same time introvert and extrovert, a coach, facilitator and leader seems unlikely. You cannot tell people what and how you want them to do certain tasks and at the same time nurture their self-esteem and self organisation. The different roles should be clear to everybody. So we (strongly) recommend using 3 physical persons, since each role needs  a different skill and mind set. We prefer clearness and opennnes over vagueness.

Interaction Agile and Project Management

Now where are the interactions between the Agile implementation phase and classical Project Management?

Business Case and Project Initiation Document, Risk register, Issue log, Change Log and Release planning are typical classical waterfall artifacts. But the input for some of these will also come from the Agile Implementation phase.

• The Business Case and PID are created before the Agile Implementation phase even has started, so no interaction possible between both worlds.
• The Risk register and Issue Log can be partially fed by the impediments and issues the DEV team addresses in the Daily Scrum
• The product backlog is the only source about the scope and priorities in your project and is the basis for Scope reporting. In the Agile world it is used to make user stories ready to be taken up in one of the next sprints by the DEV team.
• During the Sprint Review and Retrospective possible scope changes can pop-up that will be registered in the Change Log.
• Release planning is part of the Project Management, but one of the inputs for this are the velocity, derived and updated from each sprint burn-down chart.
• Sprint backlog is an agile artifact only to be used during each sprint in the Agile  Implementation phase.

Reporting

On a daily basis the DEV team, PO ans SM will use the sprint backlog to pick the correct user stories and how to implement them. The burn-down chart will be used to measure the progress of work done.

During the sprint, the same artifacts are being used to follow-up the work done during the sprint and to focus on what the DEV team has committed to. At the end of the sprint the Sprint Review and Retrospective are being held to demo and review the delivered result, and discuss what went wrong and where improvements are needed.

On a regularly basis (each 2 sprints?) a presentation is made for the Steering Committee on the status of your project. The input for this presentation comes from all the Agile and PM artifacts discussed earlier, so you don’t need additional atsks to perform as a PM:

• The Product Backlog will give you information on the scope
• Time and Budget can be derived from the burn-up chart
• Issues and Changes derive from the Sprint Review and Retrospective

Decisions will need to be taken by the Steering Committee about the issues and changes and possibly how budget, scope and time should be adapted where necessary.

Release planning using burn-up charts

To counter the preconception of classical PM’s that Agile and  long-term planning are contradictory, we will discuss the burn-up chart. In contrast with the burn-down chart which compares the planned remaining work with the actual remaining work during one sprint, the burn-up chart addresses the long-term planning of your project and releases. The names stands for themselves: a burn-down chart goes down and a burn-up chart goes up.

A burn-up chart shows us in a visual way how much estimated work we need to deliver sprint by sprint in order to reach our target release date or production date. We use the velocity (amount of work delivered by the DEV team during a sprint) which is derived from the sprint burn-down chart.. The velocity is the amount of work delivered during a sprint.

We can derive from our Product Backlog the amount of story points the DEV team will need to deliver to reach a certain release date. The user stories in the Product Backlog have been roughly estimated and prioritized. By adding all the story points of these user stories that need to be ready on the release date, we know the velocity that is needed to deliver the release on time. This is the average velocity. Based on the burn-down chart for each sprint, we know the lowest and highest velocity. This allows us to visualize the best and worse case scenario: we can now predict within a range of uncertainty when the release will be ready.

On the above example we want to measure when a certain release that contains 48 story points might be ready. Average velocity is 5, lowest is 4 and highest is 6. From this chart we can tell that the goal of 48 story points will be reached somewhere between the end of sprint 8 (best case) and sprint 12 (worse case).

You can use a burn-up chart to predict in time when a certain amount of work (release, project completion, specific user story ready or any goal to achieve) will be delivered in the worse or best case scenario. The data you need are:

• A prioritized product backlog
• Each user story that is part of the goal you want to predict should be estimated
• The average, lowest and highest velocity (derived from realistic burn-down sprint charts

You can even visualize on your burn-up chart when additional scope was added to your project during which sprint, which will result in the black line going up at a certain point in time. Otherwise your management will nor understand why the planned release date was postponed.

Conclusion

Be aware that the 3 first sprints, your velocity will be unpredictable since the DEV team has to settle with the infrastructure and the requirements, and is not yet working on normal speed. If you have historical velocity data from the same team on previous projects, you can use these data form the first sprint onwards. So unless you have these historical data, there is no way to predict upfront when a certain amount of work will be ready. You can then settle for a fixed price approach, but we all know that either the customer or the supplier will pay the bill for the added buffers in the planning and the slack in your project. And we all know that doubling the persons in your DEV team will not halve the project duration.

Of course priority changes, new user stories are being added to the product backlog and estimates are being refined. Agile claims to embrace change, so we should at least be capable of coping with this. Planning is an ongoing task and your burn-up chart will reflect more and more the current reality as more sprint and burn-down charts and velocity data become available.

I hope to see you on the next Equalminds Agile Cafe.