Working with User Proxies

My short summary of the book User Stories Applied by Mike Cohn.

In the previous post we saw different possibilities how to gather user stories.

The best way to gather user stories is to work with the users of the software to be developed. But sometimes, you are not allowed to communicated with users directly or in the worst case you even do not have users :)

In this case you have to work with user proxies. User proxy is a person that represents user but is not a user. There are different types of user proxies, and can come from different contexts. So user proxy can be:

• User's manager
• Development manager
• Salesperson
• Domain expert
• Marketing group
• Former users
• Customers
• Trainers and technical support
• Business or system analyst

User proxy can help you a lot, but you must be aware that user proxies do not have all necessary knowledge. So for example, user's manager knows something about system but will use only small part of the system. Risk is that you will develop system that will suite perfect to manager but will not be designed well for the real users. Similarly salesperson usually can explain you high level overview very well but can have problems with details. And there are similar kind of problems with all user proxies.

What is very important to remember: When working with user proxy if possible you should try hard to get your way through user proxy to the real user when ever it is possible.

To produce good software that meets user requirements you have to work with users and avoid user proxies when ever possible.

Gathering User Stories

My short summary of the book User Stories Applied by Mike Cohn.

In the previous post we saw why it is important to define roles and some techniques how to describe them.

When we have specified roles we need user stories. User stories need to be gathered somehow. Of course, the best practice is to gather user stories from user or customer. In any case, one should avoid to try to define user stories without user/customer.

Following techniques can be used to generate user stories:

• User interviews
• Questionnaires
• Observation
• Story Writing workshops

User interview is usually preferred style of user story gathering. Although interview seems simple way, usually it is not so easy. You must be able to lead interview but also to ask right questions.

Questionnaires are not so famous style of user stories gathering but can be useful if you have lot of users. In this case survey can be very good to gather information about features users would like to have.

Observation is simple but no always possible. But observing user how she interacts with your software can give you real understanding about her needs and how software should be changed to help her.

Story writing workshops can be very rapid way for generating number of user stories. These workshops are very productive but quality of workshop can depend on the meeting leader. For me, story writing workshop with right persons on the workshop is preferred way for gathering user stories.

Difference between iterative and incremental development

Do you sometimes also have problem to make clear distinction between iterative and incremental development? What if you should explain difference to customer or friend?

Hopefully these two pictures taken from Don’t know what I want, but I know how to get it will help you understand it.

When you work incrementally you are adding piece by piece but expect that each piece if fully finished. One picture is worth of thousands words :)
When you work iteratively you create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until its finished. One picture is worth of thousands words :)
So is Scrum incremental or iterative?

It is iterative by the definition as we are running sprints. We are improving application iteration after iteration.

But I believe it is also incremental because user stories finished in sprint should be of shippable quality and therefore we should not return to them in next iterations.

So Scrum is iterative incremental process.

Is this your opinion too?

User Story - Define Roles

My short summary of the book User Stories Applied by Mike Cohn.

In the previous post I summarized basic attributes of good user stories (INVEST attributes). In this post I will summarize while user roles are important.

In the most of cases in each software systems there are different roles that are interacting with it. Before you start writing your user stories you should think about roles that will interact with your system.

This way you will avoid situation when all your user stories start with "As an user...."
This way you will have better understanding what capabilities you system should have.
Having roles it may very easy happen that you will discover user stories that you would probably forget in the first moment.

How do you come to roles:

• Make brainstorm about initial set of roles
• organize initial set of roles
  
• consolidate roles
• refine roles

Of course, brainstorming should not take more than hour. After this hour you should have better ideas of user roles supported by your system.
Having roles you are able to write better user stories because very often role gives additional clarity to the user story.

There are some additional techniques for defining roles: personas and extreme characters.
Personas and extreme characters can give another view into you system but you should use them only if your project really requires that.

User Story should I N V E S T

My short summary of the book User Stories Applied by Mike Cohn.

In the previous post we saw what is user story. Now I will summarize what are the main attributes of good user story.

The main attributes of good user story are:

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

User stories should be independent as much as possible. If they are not independent it can be a problem to estimate and prioritize them.

User stories should not be contract between developers and customer. It must be possible to achieve agreement what is part of the user story.

User story must present value to user or customer.

It must be possible to estimate user story. Usually it is not possible to estimate user story if it is too big or is full of domain specific terms.

User story should not be too big nor it should be too small. User story should be just right in the size. How to achieve right size of user story? Well it depends on team an experience.

It must be possible to test user story. If it is not possible to test user story then you are not able to tell when you have finished with user story implementation.

User Story

My short summary of the book User Stories Applied by Mike Cohn

User story describes functionality that will be valuable to user or customer of a software.

User story consists of three parts:

• Description
• Conversation
• Tests

As a general rule, user story description should be written without using technical or domain specific language. It must be understandable for both, developers and customer.

Conversation is short remainder about details of user story.

Tests are used to determinate if user story story is implemented and if user story is implemented correctly.

For me very nice example of user story in the book (although it is constraint) is:
A repeat customer must be able to find one book and complete an order in less than 90 seconds.

This user story has all important features of user story:

• It is easy understandable for developer and customer
• It does not use any technical or domain specific language
• It is independent
• It is easy testable

You can compare this user story to some more technical requirements like: search in database should be performed in no more than 2 secs. User must be able to navigate easy through pages. From these technical requirements you are not able to decide what is real intention of requirements.

For me this is already enough to be ready to give a user stories a chance :)

grails excellent web framework

For long time I had kind of resistance to have a look at some "new" and exciting scripting languages like groovy or ruby. For some unknown reasons, few days ago I decided to take a very short look at a groovy. I read documentation, examples and I liked it. But that would not be enough to invest some time to learn it. But then I noticed link to grails, web framework so far unknown for me. As for past months I am deeply within web development I decided to read a little bit about it.

I have downloaded grails, opened tutorial and had hello world example in 60 secs. I couldn't believe it. With JSF combined with Facelets, RichFaces, MyFaces (what is advisable as technology stack) for hello world you need hours of configuration. Sometimes even when you use RAD tools like Red Hat Developer Studio.

This increased my courage and I continued reading some advance tutorials. Tutorial is nice and it seemed to easy to be true. So I gave it a try. I downloaded the book from infoQ and followed instructions from the book (the whole book). I didn't use tutorial because I wanted to try much wider approach than one covered in tutorial. Everything worked smoothly. For me this is excellent discovery. After using JSF and lot of surrounding technologies, I got framework with which it is really easy to create web applications. So far it seems that with grails web application development is as it should be: easy and fun.

I am sure I will continue to investigate grails and as I have some decision possibilities I hope that maybe we will do some commercial project with it.

My advice:
If you didn't try grails yet, try it right now, you will be pleasantly surprised.

Book: User Stories Applied

I am just reading the book User Stories Applied written by Mike Cohn. Book is excellent and although I have read lot of articles and blogs about user stories on the Internet I found so many new and important information for me. Everybody interested in agile software development should read this book too. As I like to have the most important statements from the book written somewhere I will place them on this blog.
This will be something like book review done chapter by chapter. But do not expect that mentioned summary of the book will be enough. If you will like the summary then for sure you have to read the book.

The list of posts I wrote about this book is:

• User Story
• User Story Should INVEST
• User Story - Define Roles
• Gathering User Stories
• Working with User Proxies
  

Start estimating in ideal person days

I am aware that this title is in contradiction with my previous post. But in previous post I was more idealistic than I should be. The main problem when estimating complexity of user story with some abstract value is that you are able to give first estimation when roughly project will be finished only after first sprint.
When I woke up and came back to reality :) it became clear that in the most of the cases this is not acceptable. Customer very often wants to know at least some rough estimation about release plan, when project will be finished. Shortly, she wants some time based estimation.

From that point of view, you should estimate first set of user stories with story points that are equal to ideal person day. As soon as you have some first set of estimations you should stop thinking in ideal person days and use them as story points. It means, when you are estimating new user story, use previous estimations for complexity comparison. This way your estimations will be based on complexity factor but later on (after few sprints) your velocity will tell where are you standing according to plan.

Estimating in story points vs ideal person days

If you use Scrum or other agile methodology you are probably aware that estimation of requirements should be done in story points. If you have investigated further, you should be aware that story point should be some abstract value that is expressing complexity of feature to be implemented and story point should not equal to ideal person day. Some good reasoning you can find here. Very often, the usual mistake is that projects use story point as ideal person day. We did the same mistake too.

There is one additional interesting consequence if you use story point as ideal person day. It can be important if you are using Scrum as a development methodology. When using Scrum, very important value for you and for your customer is velocity. Velocity is number of story points team is able to implement in fixed period of time. Usually, as project goes, velocity should increase. This does not happen all the time but happens very often.

But if your user story == ideal person day, what may happen is that in reality your velocity will increase but it will not be visible in velocity value. How this can happen.

Let say that you have estimated feature F1 with 5 SPs at the beginning of the project. What is good to notice is that at the beginning of the project you are new in the project and technology. So you have estimated first set of features with SPs (ideal person days). After a two or three sprints you are aware of velocity and roughly you know what you can expect in the future. But as your project goes on, requirements are changing and you have to reestimate changed and estimate new requirements.

But now you have much more knowledge of the project. And here comes interesting situation. You have a new feature F10 you need to estimate. Feature F10 is very similar to feature F1, but because you already have experience with the project you will estimate F10 with 2 SPs. So what we have now is that two features of similar complexity are estimated with different ideal person days. If this situation repeats for set of features, you will estimate them with the less time for development. When you include them into sprint, your velocity will remain the same but in reality you have implemented more features.

If you are good or always bad same way in estimation, your velocity cannot change during project lifecycle because you are changing value of story point. This means, nor you nor your customer are not able to notice improvements in efficiency because velocity is same (or slightly changes) all the time.

If you use first set of features as a reference value for estimating new features, you are not changing value of SP, and if you develop features faster than at the beginning of the project, you will see that in velocity.

So what will be conclusion?
Never estimate in ideal person days. Always use story points as abstract value expressing complexity of feature to be implemented.

Now, when you are estimating user stories with story points and expressing their complexity you are able to calculate and estimate your velocity.

But what should you do if you are in the middle of the project and you are already estimating in the ideal person days. Solution is easy. Stop thinking in ideal person days, select representative set of features with different complexity and use them as reference for future estimation. This way you make transition from ideal person days to user stories immediately and more or less painlessly.