Key points for a successful Agile project

Key points for a successful Agile project

Agile projects share many characteristics that distinguish them to deal with large successful projects that, managed with the traditional cascade method, are very likely to end up being diverted.

However, Agile projects may become a mess if team members are not properly chosen. For example, a multidisciplinary development team is very important, but it does not mean that anyone can do anything. It may work if all the members are qualified to cover any need. It may be good that all team members have a very high experience and expertise in applied technologies but, before that, it is even more important that each and every member of the team has a good command of teamwork.

We are going to insist in two important abilities within an Agile project that undoubtedly will contribute to the correct fulfilment committed in a sprint and the quality expected for the work delivered.

  • A highly-motivated Product Owner willing to work hard.
  • A Scrum Master with foresight abilities to detect needs.

Product Owner involved in creating good user stories

Product owner is essential in an Agile project. His planning and monitoring methods may determine the success or failure of the project. Like anything else in life, excellence is achieved with a balanced amount of quality and performance. Developing good user’s stories really useful for the development team is determinant to achieve a high quality that will have an effect in work after the first delivery. Creating good stories within a large, long-lasting project, requires full-time dedication by the Product Owner. His motivation in this work is very important.

User Stories

Methodology reveals that users’ stories must be high-level functional descriptions. They start from the following premises:

  • It must be synthetized
  • It must answer to 3 questions:
    • Who will benefit from it?
    • What do we want?
    • What is the benefit?

These questions give rise to a story written in the form as [user’s role], want [goal], in order to [benefit].

These 3 questions do ensure a very refined, high-level user’s story, but, is it enough so that the development team has all the information to develop and deliver it according to all the expectations? Maybe, but, if the product owner refines the specifications, there is an important time saving.

We can create a user’s story that says:

Description:

  1. As web user
  2. I want to be able to see the details of my products
  3. In order to prepare my reports.

Acceptance evidences or DoD (Definition of Done):

  1. Display that shows the products’ details.

Is this a valid story? Perfectly, but we leave many decisions in the hands of the development team, such as:

  • Where we show the access to these details
  • Detailed display design
  • Field of interest to be showed in the detail
  • Can we access each field to modify them?

Writing users’ stories is perfectly acceptable this way but, when the tasks are delivered in the sprint review, the product owner will introduce modifications almost certainly.

  • It would be fine if you could access al the fields to modify them.
  • And it would be great if the fields of payable products would appear in red.
  • It would help if there was a remove-field button before performing the payment.
  • It would be fine if that button…

Product Owner and User Stories

This kind of users’ stories will certainly involve that a high amount of the tasks of each sprint review fall into the next sprint to modify them, giving rise to a diversion.

A very involved product owner will use many hours to create refined user’s stories.

A user’s story like that above may include supplemental information such as:

  • Window design (a picture of a sketch is enough)
  • Browsability
  • From where it is accessible.
  • Precision in the functionality of each element of the window.

Complementing our story with these data, we will clear up a lot of doubts of the development team that, ideally, the product owner will have to clear up during the sprint, incurring into an extra time that the development team loses when it is not focused on the tasks and distraction time for the product owner.

On the other hand, only a malfunction of our window could fall in the next sprint. This functionality is very clear.

Scrum Master with foresight ability

Scrum masters play an essential role within a broad ranging Agile project.

A Product Owner must have everything ready and available to put the required tasks into each sprint. All the tasks of a backlog have been prioritized by the product owner and, when he wants to put them into the sprints, we may find an endless number of things that may hinder this goal:

  • Permissions
  • Data origin creations
  • Firewall rules
  • Server configurations

All these things are the work of a facilitator or scrum master, but a good facilitator is that that can foresight them and anticipates them. In his connection with the product owner, he can see the user’s stories of future sprints and he must be able to anticipate all the things that will need to be done before starting to work. This is, he must try to solve all the highest number of items of the DoR (Definition of Ready).

In large companies, most of the work is carried out by areas with administrative processes that usually stretch one. A scrum master with the ability to anticipate these needs will be essential to have everything available so that the product owner can carry out a successful planning.

These two points will promote the team’s concentration in the task they are working on. The first one will clarify the task and the second will contribute strongly to comply with the planning, two key aspects for our process.