The only way of really knowing for sure whether a user story has actually captured the entire end to end user need is to test it on users. Some organisations involve real end users throughout the development process, or at least have real end users involved in user testing right from the start and throughout the development. The process of user and usability testing can start with paper prototypes to confirm a concept and get feedback, right the way through to using the completed software at the end of an iteration or release.

Agile does not include anything specific about how to document anything. Agile methods tend to advocate that you produce whatever documentation is appropriate in your own individual situation and that it should ideally be lightweight, visual, and captured collaboratively just in time for development to begin. In my experience, it is common to have some high level documents over and above the product backlog. These documents might include a high level vision, some high level design concepts and sample web pages (for example) – they might also include a high level architecture (at least the key blocks) and an outline of the business process or workflow that the stories are supporting. The only thing agile would generally push back against is trying to produce detailed documentation about the entire system all up-front.

Kelly.

How does Agile document the Business Process Architecture?

Owners and Employees share some common user stories. So my question is :

Is it possible to create an user story like the following:

As an Owner/Employee I want to see all tasks assigned to me.

Please let me know if this is a valid user story.

can u email me ur response..thanks

That’s all it is really, but it’s amazing how empowering that is, how much faster you can start delivering something to test, or even some benefits, and also how you are then much more able to respond to change, i.e. be agile.

Kelly.

http://www.agile-community.com

From my perspective, I think how much you break the user stories down is very much a matter of opinion. Ideally try to break them down small, but not so small they start to become heavily inter-dependent.

Also, try to think of them from a user's perspective. I don't think a user would ever ask for fields to be validated, so I don't think field validations make good user stories. Sections of the form, on the other hand, might well make sense to split, if the form is big enough that it would be a bit unwieldy as one.

The team discuss the details of each user story during sprint planning. If, however, you have an analyst or product manager, it's entirely reasonable for them to work a bit ahead of the team and pull together some of the basics beforehand to speed up sprint planning for all involved. Wireframes would probably be ideal for this, as you don't want to go into sprint planning with the feeling the user stories have been completely nailed down. It's important for the team to contribute and have the chance to influence them too.

Hope this helps,
Kelly.

I am currently getting myself updated about scrum and writing good user stories with just-enough-details. It will be great if u can give me your inputs on the following scenario. For example I will take my Epic as to create a new screen to input candidate information. This screen should have few subsections within this, such as Personal Information, educational qualifications, experience etc. Also the user should be able to add, edit and delete these records. When I am breaking down this Epic into user stories how can I select the level to break. If I break it down to sub section wise will that be enough or should I break it further to add, edit and delete for each subsection as separate user stories.
After creating the user stories when should I discuss the fields which we are going to have under each subsection? Should this be done at the sprint planning meeting or prior to that? That is when I go for the sprint planning meeting should I go with a wire frame? They say that before the sprint planning meeting no detailed level planning should be done. However on the other hand it says ideally the sprint planning meeting should not take more than 4 hours…
For any field validation related stuff I guess I don’t need to write separate user stories and this will be discussed during the planning meeting…

Regards,
Vino

Thanks for this post.

even im new to agile but i feel the DB model can be created by logically combining the collection of approved user stories as it will help in keep and maintain data in a relative manner

more over the DB activity can be done as normally as being done with other models like sprial, iterative, RUP etc

if you get more information then do pls share about it

hth,
bhavtosh

Kelly.

As a [who], I want to [enter my information], so I can [whatever].

As a [customer service dept], I want to [make sure name and address is always entered] so I can [dispatch goods].

As a [marketing dept], I want to [make sure email address is always captured] so I can [send information about other products and services].

As a [who], I want to [check other details] so I can [capture all the important information needed later].

These obviously are just examples. In this case, I would say your overall form is a ‘theme’ (set of user stories), or even an ‘epic’ (big user story). If all the smaller user stories are required before anything can be shipped, you can clip the user story cards together or keep them in one row on the whiteboard.

When the last card is done, you are ready. But in the meantime, completion of the smaller cards gives you a clear view of progress and potentially allows the work to be taken by multiple people.

Kelly.

But, I need help on splitting a user story into small stories. I have one complicated screen will difficult business logic. How can I split this story? Is there any ground rules for splitting user story?

Can I define development of UI as one story, then implementing validations as another user story and finally the business logic as one story?

That doesn’t mean the story isn’t useful. But I think it’s important to have a separate set of stories that express the real requirements.

One of the things I love about Agile methods is that it’s so easy to get collaboration! Because now we’re drawing all over 3×5 cards and whiteboards, as opposed to typing up one person’s “rough draft” and handing it out.

Agile purists would say don’t look too far ahead, because things have a habit of changing, so too much up-front analysis can be a waste.

Instead, build one feature at a time, and if (for example) on feature 2 you find something in common with feature 1, “refactor” feature 1 by pulling out the common building blocks and use it on both features 1 and 2.

Keep going like this as you work through your product backlog, and you will only produce building blocks that are definitely needed, regardless of what might change in future, and you will not waste any time analysing and designing features that may not get done if priorities change.

Of course if you have a high degree of certainty about features (not looking too far ahead), and you can see they have something in common, it would make sense to design it with some of the important building blocks in the first place.

In my view that’s absolutely fine and it’s about finding the right balance that works for you. However I would certainly encourage you not to go into too much detail too far ahead, and not too think of refactoring as unnecessary re-work as it saves an awful lot of time compared with trying to understand everything up-front.

Hope this helps,

Kelly.

You could split into smaller user stories as you suggest, and keep them together as one ‘theme’…

Kelly.

Regards
James