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.

Software estimation is the ghost of the process, always is difficult to estimate how much time it will cost, you can do it in different ways, with different techniques, by intuition, by the quantity of code lines or story points, by experience of someone or because you compare the project with other projects.

In the last meeting of agiles@bsas we were talking about software estimation in agile projects, we were discussing some different techniques. One of them is known as Planning Poker and I found it very interesting and let me explain why.

Starting the Estimation Process

To start the process someone tell what are a user story about, then all the people think which is the cost of this story and tell to the others. Up to this point all be right excepting for something that I take notice after some projects: the first person who say which is his estimation influence the decision of the others.

Imagine that instead of saying which is the estimation of each member you write it in a peace of paper and facedown and then all the papers turn over, no one knows what is written in the other papers, so there is no influence.

Planning Poker

The planning poker is a funny way to do the paper games but using a deck of card like this one:

You can notice that there aren’t all the numbers. This is because the objective is that estimation is not accurate, so each card must be bigger enough  than the previous.

So, after the user story explanation, each member put his card face down, and all together turn over. If there are lot of differences between  the estimations they discuss his opinions and re-estimate. If there are agreement the estimation is over.

Some considerations

• If a user story needs one hundred card it means that is too big or is incompressible, so the client or the Product Owner must divide it to decrease the complexity.
• When someone put a zero card it means that this task is already done or should take no more than a few minutes of work.
• The cup means that the team member is tired to think and need a break.
• The question mark card means “I have no idea”. If this card is used too often, the team needs to discuss the stories more and try to achieve better knowledge spread within the team.

Sometimes you have to explain someone what agile means, you start talking but the other person seems to misunderstand every word you said. So how do you explain agile culture to this person?

I’m going to tell you what happened to me last night…

There are 8.45 pm, I arrived to my boyfriend home hoping that he has bought something for dinner. Fortunately he had!  He was craving to eat chicken with Champignons’ sauce,  easy to prepare if you have the right things…

So I open the fridge and start preparing the dinner. A bit of this, a bit of that… and suddenly… oohh ohhh! Where is the cream darling?

He forgot to buy it, chicken is cooking and the sauce is in middle of preparation… I have to replace the cream!

I open the cupboard, the fridge and start to look for something that can help. Thinking a bit I found some pieces of different cheeses, so I change the dinner… Chicken and Champignons with Chesses sauce!

I found this experience similar to agile software development, you have something to do, but you could found some issues, requirements could change and YOU, the agile team, must be prepare to adapt to this changes!

I want to share with you my first experience at Agiles@Argentina, this is a little (but growing) group of people that enjoy sharing their knowledge about agile practices and how they apply this on daily work.  In my last post I talked about this meetings.

Last time we were talking about “What do you do in your first iteration?” and I would like to present some of the models proposed in that talk.

Some of the participants announced that they were using Scrum. However, I found an interesting difference, all of them talked about short Sprints, but the duration of this Sprint various between one and four weeks depending on the speaker.

Another speaker announced that their projects always start with a Retrospective meeting where the team discuss about “Which are the objectives for the project?” and “What could and could not be done taking into the experience of past projects?”

I also note that almost always the project initiate with a pre-sales process where they can take the “big picture” of the client requirements and then they formally start the project delivering in the first iteration a piece of final product which is made of:

1. Architecture document
2. Product Backlog and User Stories
3. Iteration Planning

Now I invite you to tell me and all the readers what do you do in your first iteration? what do you deliver? and How do you estimate what shall you do in each iteration?

If you want to share or learn something about agile estimation this is the topic of the next meeting (Tuesday July 14) at Microsoft Argentina offices, you can register here.

Sometimes I have heard about some business that are committed to their projects, so the employees must working overtime to deliver projects on time.

I have heard in some occasions a project manager telling someone that he is not committed with the project because this person doesn’t stay at office more time than expected.

Personally, I think if people often need to do overtime is a clear fault in project management. You know the capacities and capabilities of your team. If a team regularly need to do overtime there are a problem.

I have write some time ago about Scrum. This methodology works over personal commitment of each member on the team. Teams are self-organized. Each member knows his timetable, and commit to do what he is sure he could do in this time.

So, if a person is committed to the project success must do overtime to complete it? Answer is no. You have to be realistic on your commitments, you have to be committed to do this things that are possible.

Is known that any person can works as a robot for to much hours. As the hours runs the ability of concentration diminishes. Its not new. There are some studies that said that making overtime can improve the velocity and quality of the team works in the short-term, but with some days employees start to get tired and people make mistakes and lose incentive to do high quality work. Results gets down! 

Don’t confuse personal commitment with working overtime.

Personal commitment frequently leads to developers working overtime to finish their tasks. However, overtime is not a requirement of personal commitment. You can be really committed with the project, also with your time-box planification.

A personal piece of advice: Hard-working is ok, rest & social life too. Keep balanced.

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!

Today I want to share with you a little about Scrum.

Scrum is an agile product development methodology, note that I say product and not software. One of the most important of this methodology is that can be applied in any product development but this has been thought to software development.

Some approaches of this methodology have been used for years. In 1986 Hirotaka Takeuchi e Ikujiro Nonaka wanted to increment the process flexibility and agility of they business, they used transversals team (like rugby) where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. During some years it has been modified. In 2001 Schwaber y Mike Beedle wrote the first book where this methodology was officially called Scrum. This book is “Agile Software development with Scrum”.

How does Scrum work?

Any development project starts with a necessity, this necessity is expressed as a list of requirements that we must fit to satisfy the client, also the client specify which of this requirements are more important and prioritize them. This list is known as product backlog. This product backlog could change during the project; the client could add, remove or reprioritize requirements. When all the requirements of the product backlog where delivered the product is finished.

Scrum’s process starts with a meeting called sprint planning; there a subset of requirements of the product backlog (the highest prioritized in the list) are committed to done in a small period of time called sprint. This subset is called sprint backlog.

Each sprint is a time-boxed period of time (between one and four weeks – depending on the project) where team commits to transform the items in the sprint backlog into an increment of the product; all the requirements which are included in the sprint backlog can not be changed; consider that the sprint backlog should be shipping at the end of the sprint, so IT MUST BE REALIST.

During the sprint, a daily scrum meeting (also known as stand up) is done; there each member of the team has to communicate how his work is going. This has the purpose to synchronize the whole team.

When the sprint ends two meetings take place the sprint review and the sprint retrospective. At the sprint review the teams shows what is done during the sprint, at the end of this meetings the sprint retrospective meeting is done where the team looks for improvements in the process.

After the sprint is complete, the iterative process should start again in the same way. With each sprint you have an increment of the final product. When the product backlog is completely delivered the Scrum process is finished.

The Scrum roles

Scrum determinates two classes of roles, the committed roles and the involved roles. An easy way to understand them is with the very well-known “pig and chicken story”

 The involved roles in Scrum (chickens) are all the people who are interested in the project, who have something to gain if the project is successful. Some of this people are final users, stakeholders, business manager, etc.

Who make the project successful? All the people who are committed to do that (the pigs). The pig roles of Scrum are the following:

• Product Owner:  Something interesting about Scrum is that includes the client in the development process. The product owner is the client, or a client interests representant inside the team. He is who defined the product backlog and prioritize each requirement.

• Scrum Master: he has the responsibility of ensure that the Scrum process is met. He also has to remove impediments to the ability of the team to deliver the sprint goal. 

• Team: is a group of people who has the responsibility of transform the product backlog into a product. The team must be made up with no more than 7 persons, normally between five and seven, with cross functionality. The most important of the Scrum team is that they are self-organized; they must be capable of creating its own dynamic orderliness. In scrum there is not project leader.

Scrum meetings

All the meetings are time-box. What that it means? Each one has a fixed duration, in this time they have to solve all the items.  

• Sprint planning (8 hours or less, depending of sprint duration). This meeting is divided in two phases of 4 hours. In the first part of the meeting all (pig and chickens) are invited. There, the Product Owner explains the highest requirements on the product backlog and the team decided which will be the goal of this sprint, and put this in the sprint backlog. In this part only the pigs can talk. The second part of the meeting is only for the Scrum team; in this time they decided how they will develop these requirements, and which one is the responsible of each task. 

• Daily Scrum meeting (15 minutes). This meeting has the purpose of synchronize the whole team; each member in the team has to know how the sprint goal is going. In this meeting each member of the team must answer three questions to communicate to the whole team how the goal goes:
  1. What have I done since last meeting?
  2. What are you planning to do by the next meeting?
  3. Do you have any problems preventing you from accomplishing your goal?

This meeting is also known as Stand Up because the team members stay stand up to maintain the quickness of the process. Something important is that all team members must be punctual. Some teams tend to put a fine (e.g. 1U$D) for assure this rule is met. Everyone is invited, but just pigs can talk.

• Sprint Review (4 hours or less, depending on the sprint duration). At the end of the sprint the sprint review take place. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

•  Sprint Retrospective When a sprint ends and after the sprint review the whole team makes a close retrospective meeting where they reflect about the past sprint and each team member must answer two questions:
  1. What went well during the sprint?
  2. What could be improved in the next sprint?

Who use Scrum actually?

Large companies like Microsoft, Google, Yahoo and Verizon. And others no so large like Thoughworks.

Conclusion

Scrum works because is made based on common sense, and considering that software is made by people, human beens.

A book called “The agile software development: The people factor” say “agile development focuses on the talents and skills of individuals, as the process complies with the specific people and teams” the most important of this affirmation is that the process complies with people and not vice versa.

Which are the people factors that make an agile software development successful?

• Competence:  the process ability and knowledge can and must be taught to whole team.

• Common approach: whole team have a goal, this goal must be deliver a software increment to the client in the promised time.

• Collaboration:  all tasks will complete if the team members collaborate with each other, clients and managers.

• Ability to make decisions: team has autonomy and authority to make technical decisions.

• Problem solving skills: All change. Team has to accept that the problem that are solving now is not the problem that will be solving tomorrow. 

• Trust and mutual respect: a book called “Peopleware” says that the team must be match so strongly that the whole is grater than the sum of its parts.

• Organization:  team organizes itself, the process and the work plan. This enhances collaboration and increases the morale of the team.

This is one of the based of agile culture. 

Any agile software process is characterized by fulfilling three key items:

• Is difficult to predict which software requirements will survive and which of them will change.  Also is difficult to presage how can change the client priorities.

• Software design and construction are made in the same time. You never know how much design you need until it’s used by construction. 

• Analysis, Design and Construction are unpredictable. So the planning is very difficult.

An agile process must be adaptable. And a software process must adapt incrementally using the client feedback. Software increments have to be delivered in short periods to maintain a good rate with change.

We know that nobody is against the agility but there are a lot of people that question about things like “How can we built software that satisfy clients needs with a quality level that allow developers to extend and escalate to meet the client needs in the long-term?”.

There are a lot of agile methodologies that adopt and adapt software engineering good concepts. And is important to know that is possible to built quality software with agile.

I will be writing about agile and conventional software development methodologies to discover the strengths and weaknesses of each one.