Once we have a clear idea of what has to be done, we try to organize project requirements into a format that it is more usable for software developers. This can be in the format of Use Cases or User Stories. The advantage we see in these formats is that they provide a clear guide to both the client and the developer of a valuable goal that can be accomplished with the system under design. So, the developer will work on a task until the goal can be completed with the software.

Each work item (either use case or user story) will receive a “weight” estimation from the development. This estimation is based in both the time needed to complete it and the complexity it may involve. Based in previous experience, we can then translate this weight into hours or days.

Apart from the development work items, there are other tasks that are often forgotten like, project, environment and team setup, meetings, planning, testing, project management and data transformation, among others. All these tasks also add up time to the estimation.

Predicting how long a project could take is very difficult and practically impossible. As humans the amount of work we can produce per hour varies very widely. There could be days when we get distracted easily and other days we are much more productive.

This post is intended for customers to understand the implications of using this methodology and how we implement it in our daily work.

Scrum is an agile development methodology based in the following principles:

• The customer or Product Owner has an important involvement in the development process.
• Product requirements are defined with the Product Owner (usually as User Stories) and put together as Product Backlog Items. It is a desired practice that Product Owner actually writes requirements.
• Product Owner prioritizes the Product Backlog Items in accordance with its business value.
• Product Backlog Items are estimated, whether by time or relative weight, only by the development team. This estimation is adjusted constantly, usually at the start of each Sprint.
• The development cycle is divided into time-boxed Sprints of a fixed duration (typically 2 to 4 weeks). Each Sprint has a clear Sprint Goal and produces a working product increment.
• Before each Sprint starts, a Sprint Planning meeting is done to choose which requirements are implemented and the details on each are discussed. The whole development team and Product Owner participate.
• The requirements that are implemented in a Sprint constitutes the Sprint Backlog.
• Once a Sprint starts, no changes are accepted for the Sprint (bugs could be an exception).
• A Daily Scrum meeting is held every morning only between members of the dev team. This is a short-stand-up meeting where each member communicates: what he did yesterday, what he will be doing today and any impediment he is facing.
• At the end of each Sprint a Sprint Review or demo is held where the team demonstrates the product increment to the Product Owner and any other involved stakeholder.
• At the end of each Sprint, a Sprint Retrospective is held to discuss what it is working and what it is not.

How we define what to do

It is important for us to clearly understand what you want to do. We usually like to put this on a Project Vision document. Customers often think that, as we developers we are not interested in the business background for a project. Well, not only we are very interested but we strongly need to know all the aspects of the business related to a project in order to understand the project and to make key decisions in the design and implementation stage of the development cycle.

A Project Vision document contains all available thinking about what a project will be. It defines the goals of a project, why they make sense and what the high-level features, requirements or dates for a project will be.

The most important points to cover in the Project vision are:

• Vision Statement. This is usually a once sentence that describes this specific release of the project. This is also known as the problem statement because usually projects are planned to solve a specific problem.
• Project Goals. Describe how this project contributes to the goals of the organization, customer or final user.
• Business Opportunity. Describe what is the current business situation, what users’ or customers’ needs are not being satisfayed, what competitors are doing or offering and how we can change the world with our solution.
• Users Description. Describe who are the customers, what problems does this software solve for them and why they would use or buy the software.
• Stakeholders Description. Who are the stakeholders (people with power on the project but not necessary the users/customers) and what role they have in the project.
• Product Features. This section describes the high-level features for the system. We prefer not to employ use cases here because they are too detailed and usually people reading the Project Vision just want a short overview identifying the key functions. User stories could be a list too long to describe in the Project Vision. That’s why prefer to write it as a list of features. It is important to differentiate between essential features (priority 1) and desired-but-not-essential (priority 2).

• Other topics could be Risks and Assumptions being made and Dependencies on other projects, companies or organizations.

How we define requirements

Requirements also define “what to do” in a project, although, with a deeper level of detail than what can be found in the Product Features of the Vision document.

There are several types of Requirements. We classify them as Functional and Non Functional (Usability, Reliability, Performance, Supportability, Implementation, Interface, Operations, Deployment and Legal).

Functional Requirements are among the most important because they define the core of the system, what the system must do, its features and capabilities. Functional Requirements are usually defined as User Stories or Use Cases.

We strongly think that requirements should be written by the customer with one or more members of the development team or, at least, participate actively in the requirements definition.

The best method to involve the client in the definition of the system requirements is by using User Stories because they are easier to conceive and because they are formulated in a more natural and spoken language.

User Stories

User Stories define a goal that a specific type of user has when using the system, in a natural language. Although it is not necessary to follow it, we use this format to describe the User Stories:

As a [type of user], I want/can/need/etc. [goal or need], so I can [reason].

An example of a User Story, for an e-learning web site could be:

As a Teacher,I want to create an online test, so I can measure the level of the students.

User Stories have a more important advantage. They are an easier method to have non technical involved people define requirements. For example, it is easier for a Product Owner to write a list of requirements in this format than in the format of a Use Case diagram or a list of Use Cases.

User Stories emphasize verbal communication, in comparison to written language. The use of the first person to describe the goal make them sound more natural and tend to avoid misunderstandings typical of a written document.

We strongly prefer to define Functional Requirements as User Stories or inspired by them (because sometimes they could be too long) because they are a lot much easier to discuss with clients and users.

All the User Stories (or Use Cases or Features, depending on what we decide to use), along with any other requirement that is expressed in any different way are put together in the Product Backlog. This constitutes all what has to be done to complete the product.

We define the Product Backlog in a System Requirements Specifications (SRS) document and we manage it (time and resources) using a spreadsheet. The SRS document could contain additional information about each User Story. The Non-Functional requirements are also described in the SRS.

Acceptance Criteria

While the Product Backlog defines all what has to be done, sometimes it is risky to give the customer a fixed estimate or quote based only in simple User Stories or Features.

To solve this we sit together with the customer and go through each User Story and define what we call the Acceptance Criteria. This describes the high level features a User Story has to meet and the Tests it has to pass in order to be accepted as complete either by the development team or by the customer.

Examples of Acceptance Criteria for the above User Story could be:

Resources

Scrum Video: http://www.youtube.com/watch?v=Q5k7a9YEoUI
Scrum Presentation: http://www.mountaingoatsoftware.com/scrum-a-presentation

Bibliography

The Art of Project Management – Scott Berkum

UML and Patterns – Craig Larman