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 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.

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.