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.

What a Pomodoro is?

A pomodoro is a kitchen timer, and we will use it to control and administrate our time. We will set the timer duration on 30 minutes, 25 minutes of work and a 5 minutes break.  When a pomodoro starts it can’t be stopped, it’s indivisible. After four pomodoros you have a longer break (15 to 30 minutes).

Maybe you are thinking about the title of my post, this means that the recess must be respected, and it based on the idea of Francesco put in his book:

This leisure time is fuel for our minds. Without it, creativity, interest, and curiosity are lost, and we run ourselves down until our energy is depleted. Without gas, the engine won’t run.

How can this technique works?

You have your timer and are ready to start working, but what you will do? You have to do a list of your planned tasks in order of priority and a section labeled “Unplanned & Urgent Activities” where any unexpected tasks that have to be dealt with should be listed as they come up.

If some interrupts the pomodoro it can’t be consider complete. When a pomodoro rings you have to do a cross next to the activity you have been working and take your 5 minutes break. This time allow you to disconnect from work and do other activities which take a little time.

When you finish a task you have to cross it out, and remember that a pomodoro is indivisible, so if you have time left use it to review all the things you have done, but if you finish it on the five first minutes of the pomodoro you can void it.

Up to this point all be right, but what happen with interruptions, sometimes appear and it can be consider a real problem, so you have to learn to manage all of them. Interruptions can be urgent or not, imagine you are in the middle of a pomodoro and realize that you are really hungry and want to eat pizza, or maybe you remember a concert and you want to call a friend to invite him.

This interruptions are different, but if you postpone them you don’t have to void your pomodoro. You take note of that and continuing working. To control the interruptions you have to do a mark on the activity, use different marks to different types of interruptions.

Francesco said:

The first objective to achieve in cutting down on interruptions is to be aware of the number and
type of internal interruptions. Observe them, accept them, and schedule them or delete them, as
the case may be.

The second objective to achieve in order to cut down on interruptions is to be aware of
the number and type of external interruptions. Negotiate them and reschedule them depending
on the real degree of urgency.

This is the first step of applying this technique, then you can set your available pomodoros and estimate your activities to do the technique more effective. You can download the book and continues improving.

How can it be related with software engineering?

Some people use this technique to do development tasks, and some mix it with agile methodologies, but some people said that it can bring some problems because individuals may tend to meet personal goals and not team goals.

I invite you to talk about your experiences using the pomodoro technique in both scenarios, personal and team work.

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.

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!

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.

Particularly in Buenos Aires, the meetings are scheduled the 2nd Tuesday of each month in Microsoft Argentina offices. This time they will discuss some related topics like:

• How to initiate projects
• What do you do in fist iteration?
• What do you deliver at this time?
• How do you estimate?
• What are your decisions?
• What are the activities you do at first time?

They use Lightning Talks, 3 slides in a slot of 7 seven minutes to share what you do and what you think.

I invite you to visit and join this group to take notice about the places where are organizing other meeting, some agile training courses.

See you!

• If it Works, do it!
• If it Works, do it! It woks
• If it seems to Work,do it! It probably woks
• If it seems to Work, do it! It probably woks (and might work again)

Really it is not a manifesto, there aren’t a group or association investigating and promoting that. So if it isn’t a manifesto… What it is? It’s a phenomenon around the world where people who have worked with different agile methodologies and have decided to move on. 

Investigating a bit more about this topic I found a Post-Agilism FAQ at Jonathan Kohl’s blog which said:

Post-Agilism is:

1. a growing movement of former Agilists who have moved beyond Agile methods, using a wide variety of software development tools and methodologies in their work.
2. an emerging era. Now that the Agile movement has moved to the mainstream, what’s next?

Some people think that the post-agilism is  a fallacy, and that the people who consider part of this group are anti-agilist and “process mash up”. In this same article Kohl explain why they consider that this accusations are false.

Personally, I use Scrum and consider that the failure of agile methodologies are because people try to change and mix methodologies to adapt it to their necessities.

What do you think?

In 1990, Kapor deliver a software design manifesto where he has eloquently made the case that we need to think of software design as a profession, rather than as a side task of a manager or a programmer.

The most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience…. What is design? … It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together.

Some important is that software design is not UI design. And neither software engineering nor computer science are software design.

Design disciplines are concerned with making artifacts for human use … One of the main reasons most computer software is so abysmal is that it’s not designed at all, but merely engineered

He consider that software designers are the architects of software which has the responsibility of integrate design and software development; architects and engineers are involved in building the application, and programmers are who develop the application. A perspective and skills that are critical to good design are typically absent from the development process, or, if present, exist only in an underground fashion.

A software design manifesto.

Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software.

A good software design must have:

• Firmness: A program should not have any bugs that inhibit its function.
• Commodity: A program should be suitable for the purposes for which it was intended.
• Delight: The experience of using the program should be pleasurable one.

Mitch Kapor wrote this manifesto some time ago. Do you think this is still accurate? Why?

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.

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!