Milena Mastrasso

In other posts I mention about Scrum and the use of User Stories to estimate and schedule your project. Today I focus on  what a story is and how do you write this stories.

What is a User Story?

A user story is a description of a valuable functionality of the software. Much development teams write this stories in cards which are divided in three important parts:

• The description: Is the main part of the user story, it must be brief and you should notice that this “represent a customer requirement rather than document it”

• The conversations: All the stories must be discussed with the team. In this conversation some important details come up. This details give a better approach for the development and you could write it briefly here.

• The test: are based on the expectation of the project’s users and are written as Acceptance Test, a reminder on how to test. This are meant to be short and are written on the back of the card.

What is a good User Story?

You need to focus on some attributes that a good user story should consider. A good user story is:

• Independent. Is important to not introduce dependences between stories. Dependencies create problems with planning and prioritization. For example if you have a user story for each credit card you can estimate some hours to the first one, and much less to the other, is better to combine them in only one card.

• Negotiable. Cards are not a contract, it’s a reminder of what you have to do, are little descriptions of required functionality, details have to be negotiated in conversations.

• Valuable to user or customers. You must avoid stories which have value only for developers, like connections to database or error handling.

• Estimable. Stories must be estimable, if the developers lack the domain or technical knowledge or if the story is too large may be inestimable. You can split big stories to be able to estimate them.

• Small. The story size should be the right size, if them are large or small can’t be well estimated. Right size is determined in the velocity team and the used technology, you can combine or split stories to make it the right size.

• Testable. Stories need to be testable, must be written to be tested.  Successfully passing the test proves that the story has been successfully developed, and show the development team when they have finished coding. Some test could be automated, others require human intervention.

What more should I consider to improve user stories?

To improve user stories you have to consider the user roles, the details included on the cards. This things with others will be explain in other posts.

I work as business analysis. I have learn traditional business analysis (like Unified Process, Cascade, between others), but I found some problems with this and other prescriptive methodologies. One of this problems, in my opinion the most important, is that this type of methodologies consider that the clients always know what they want, and could explain it in the right way.  In addition all the prescriptive methodologies consider that documenting before development is important, and this documentation won’t change. My experience said that it is unfortunately false.

Some time ago I used to be a .Net developer when I start reading about agile software development. I found it really interesting because it focuses on the working software, it allow teams to develop high quality software and produce retrospective in the short-term. I consider this important things to do a successful project.

So I start thinking about the business analyst role in agile methodologies, because one of the agile manifesto rules said:

Working software over comprehensive documentation

If business analysts don’t spend several hours of their working time documenting, modeling and writing about lot of requirements. What are their responsibilities?

The business analyst must collaborate with the team.

As I mention in one of my last posts about people factor at agile software development, collaboration between all the team members is essential. Business analyst is the expert on understanding client requirements, he knows what the client is expecting about the system behavior. He will spent more time collaborating with whole team working on how the system will behave instead documenting.

Some projects need to write requirements because organization formality requires it.

How does the business analyst document this without investing too much time on it?

Requirements and specifications are written as user stories. A user story is a description of a requirement, but it is not a full specification.

Besides user stories describe a functionality, this are also useful to prioritize requirements and estimate costs.

Each user story could be code in an iteration or increment, so the specification must be smaller enough to could develop it in a small period of time, but it must be detail enough to estimate the work. Every user story must have acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it.

In addition, user stories must avoid dependencies of other stories, but you can combine some of them to deliver in the same iteration.

Which skills are needed to be an agile business analyst?

I mention before that business analyst have to document requirements in a different way, less detailed. So he must learn a new way of writing and documenting.

He also have to improve his communication and collaboration skills because he has the responsibility of translate business requirements to the technical  members team. He is not the unique responsible of making specification, he must work in group and involve other team members in this activity.

If the business analyst have good concepts of software architecture will help to reduce the gap to the development team and the business. He can understand and explain better how the system will be implementing.

Is the business analyst needed in any agile software development?

Some projects don’t need a business analyst,  sometimes a product owner (view my post of Scrum) is enough. When the project has a grater need of defining requirements and writing specifications is business analyst is added in the agile team. However, including a business analyst can perform the team comprehension requirements.

Conclusion 

Software development processes are changing, any time much more business adopt agile methodologies. The biggest business (like Google, Microsoft, Yahoo) are using Scrum, other business are adopting this or other agile methodologies. They consider that adopting a methodology that give flexibility and quick response to changes is very important.

I think that a good business analyst must work on acquire and improve some skills to be competitive in the actual market. If a business analyst wants to work in a agile software development is completely possible.

He has to learn a bit about agile methodologies and is necessary that he wants to works in groups with cross-functionality. It is a way of sharing experiences and knowledge, this makes it possible to learn from each other.

Come on, it’s not so difficult!