0

I am very new to the agile software development and trying to understand the size rule to be followed when writing a valuable user stories

Scenario

I am currently involved in a portfolio data import projects. This involves setting a import and export functionality between the application and adapters. However the import/export functionality is implemented for couple of adapters. How will handle the user story of a new adapter - import/export setting. the functionality is same for all the adapters. I would like to clarify the below doubts 1. should we repeat the content of the user stories if the functionality is same 2. should we write more detailed stories or shorter one

Improve this question
4
  • What do your related user stories and backlog items actually say? Please provide one or more concrete examples.
    – Todd A. Jacobs ♦
    Sep 18, 2018 at 11:08
  • @ToddA.Jacobs User story involves the implementation of the below features in different adapters 1. Portfolio Import Mappings 2. Portfolio Import Settings 3. Portfolio Data Import 4. View results of Portfolio Data Import
    – Jithin Antony
    Sep 18, 2018 at 11:41
  • I mean "include some actual stories in your question." We prefer concrete questions with specific details, and want to avoid hand-waving of any kind.
    – Todd A. Jacobs ♦
    Sep 18, 2018 at 14:21
  • Don't worry. Story sizing is often tricky. My thoughts are below.
    – Shawn Adams
    Sep 18, 2018 at 19:58

3 Answers 3

Reset to default
3

There isn't a "right" answer. However, there are a few points about user stories that you may find helpful in guiding your decision:

1) User stories were originally written on 3x5 cards. This was intentionally selected specifically because it was impossible to fit all of the details on a card that size so developers would have to talk to the user or PO and write their own notes from the conversation.

2) User stories should express the need being resolved, not the implementation. That means that for something like import, the start of your user story is probably as simple as:

As a new user, I want to import my data from a flat file so that I don't have to type it all in by hand.

and maybe include a copy of an import file as example.

Improve this answer
0

Generally a User Story is work that can be finished in one Sprint.

If yours will take longer it would be considered to be an Epic, which will contain additional User Stories within it. If those additional Stories appear to be similar but have different Acceptance Criteria they should be written as separate User Stories.

From this side of the screen it feels like you should break that story up. Good luck!

Improve this answer
0

The Development Team and Product Owner should work together to summarize acceptance criteria for each piece of new functionality. If there is crossover in value delivered from other pieces of done work, that completed work can be referenced in all new work items being generated for the product. This provides context and a framework for approaching new work while keeping existing functionality in mind. If the new work being generated is large enough in scope, the Development Team should be empowered to manage/break up the work as they see fit before bringing it into their sprint.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.