Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm reorganizing my agile board on youtrack and am trying to conform to the industry best practices however I would much rather call an epic
"User Profile"
as opposed to
"A users can view their own and other users information and content on their user profile"
if I can get away with it.
I'm going to be applying for jobs soon so theres a chance someone might look at what I've done and I just want to make sure I don't look bad because of something like this.
To further clarify how I view each "Type" of issue (to make sure I'm understanding them correctly)
Epic - User Profile (brief description)
Feature - User Feed (detailed description)
Task - A user may like items in the feed
At the time of writing the epic stories, probably you don't have the same clarity level on what the customer really want.
So the epic title might be "User Profile" while later on when you start creating the user stories; the user story title "As user I want to be able to update my profile so that I can add avatar".
The title of an epic should be 'fit for purpose'. What that purpose is depends on how you are using them.
For example, say you were the only person who had visibility of the epics. In that case the epic title should be something that made sense to you. If, however, the epic was visible widely across business users then it would make sense to use an epic title that means the most to them.
There isn't really a 'best practice' when it comes to this kind of thing as agile approaches vary so much. Really it is about finding a solution that works well for your particular organisation and if it doesn't work well, adapting it to be better.
I would suggest the only situation you absolutely want to avoid is having epic titles that are meaningful to the delivery team, but not understood by the business users.
There is really no logical difference between an epic and a story; the distinction is one of scale. In fact, it is often the case that a story becomes an epic when the team estimates it to be relatively large.
We find it really easier to go through the product backlog items, specially when we are trying to rank them by showing a title which sum-up the main purpose behind the user story and if more details is needed then we dig into it to check the whole user story with it is acceptance criteria.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work as a UX-designer and have some experience with user stories from agile development projects where they were used to document functional requirements on the form:
As a [type of user] I want to [goal] so that [reason]
After a discussion with some colleagues we identified three different interpretations of what a [type of user] is supposed to be.
For me as a UX-designer the [type of user] would represent a persona, an
archetypical end user or customer built from user research on real
people.
One of the developers said the [type of user] was a role in the
software, for example a medic or a sniper in a war game.
A project leader said the [type of user] represented team roles
in the development project, for example a tester or a developer.
Who is right? If all of us are right, wouldn't this be a common source of confusion?
User stories are written in the language and from the viewpoint of end users of the product.
So the user's are exactly that: they are users of the system.
Examples include:
A doctor using some medical software
A shopper using an online shop
A product manager using a product report
To answer as short as possible: the person is a "stake holder".
Now what is that stake holder? It is the person having the (biggest) benefit of the story tasks to be performed.
Most general it's the app user. It can use a new feature.
It could be a developer, e.g. the story could intend to make an app more resilient
It could be your manager, maybe there is a risk to be closed
And many many more. As long as it's getting benefit of this story to be finished.
(side note: I never liked this way of story writing. too many boilerplate, but also our agile coach urges us to write stories in this format)
1 and 2 are very common in use. I've worked with many teams who created a number of persona's for their product, say Jane the elderly lady, Daphne the hipster who does everything with her smartphone and John the executive who lets everything be arranged by his personal assistant.
These personas have very different requirements of a piece of software even though they may be performing the same function in the system or are acting from the perspective of the same role.
The value statement for one may even conflict with the value statement for another. Where Jane might want a large font and only the information relevant t her current action, John ('s assistant) may want to have a broader view and doesn't mind visualizations and small fonts if it means she can cram more information on the same screen.
So see the personas as a way to further scope down specific roles and make your user stories more "human" by staying away from tightly scoped roles. Remember, the user story is meant to really tell the story of a user and what the functionality will help him/her accomplish and what that would bring to these people. The roles "administrator", "customer", "gold customer" tend to be empty of emotion and often don't lead to the right discussions.
I remember some team discussions where people remarked mid-discussion: "While John would love that, we'd have lost Jane 3 steps ago". Which lead to a change in the proposed functionality.
As for option 3, I see quite a few teams do that, and for certain roles it may make sense... As a operations engineer I need thorough logging in order to analyze production incidents quickly. could be an example. But teams taking it to As a requirements analyst I need the requirements for story 27 is taking it too far. Often these items fall in the non-functional requirement bucket and do not provide true end-user functionality. For these types of Product Backlog Items you may need to check whether a User Story is the best format to describe them.
The first and second are right but they are not different, rather are complementary.
Type of user can be:
Joe a person.
A banker, some rol.
Joe the banker, a person that have a rol.
In resume you can use any context for a type of user, so you can use one of them or a mix.
Hope my english can be undertand =).
TL;DR
All are useful, none are wrong and none are the only way. Read more on a blog post I wrote to follow up this answer.
The 3 nuances you describe are each valid and provide useful information. Consider trying each to see which works best for you. My advice would be to avoid restricting what 'user' can mean as it may cut you off from useful insight and deeper meaning into what you're building
The goal of a user story (originally, Kent Beck wanted them to be just called 'stories') is not to write better user stories; it is to go beyond requirement and into true understanding. For this, you need to who who the software is for, what problem it is solving for them and why that problem is valuable to be solved.
Consider this as an experiment to know if you have the right type of user. Answer the question, "Do I know how this thing I'm building will change the world of those who will use it?" If not, you may not understand yet who it is for.
User stories best used to describe the requirements from the product backlogs so that how the end user or stakeholder will see and use the product from his point of view. And PO should be the best person who can comment about the correctness of the user story. If PO is taking input from team for the development of user stories, the one should visualize more on the usage of the product rather
than simply classifying the type of user. Though the type of user are important, but the emphasis needs to be given to usage such as,
1. the doctor accessing the medical website to know the content of the drug and its manufacturer so what kind of access needs to be given to him on the other hand
2. if the druggist is looking for the particular drug, available quantity, shipment time then according access and workflow needs to be provided.
From the above given usages, I find the 1st one as appropriate i.e. persona and its the usage of the system from his point of view. For each usage of the system, one can create user stories and accordingly the workflow can be developed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team have recently gone to sprints and we are going through breaking down our user stories into tasks. What is the best practice in breaking down the user stories?
Should each task include developing, design, testing, and so forth? Or can the tasks be individually broken out? If so, should the tasks that aren't testing related just go straight to done and skip "Verify" or "To Test" column in the workflow?
From what I've read online it seems there is no 'set' way and people do it differently. I'm curious if people have had problems with their way of doing it.
Any help would be useful!
What is the best practice in breaking down the user stories?
Splitting user stories: the hamburger method
Elephant carpaccio
Should each task include developing, design, testing, and so forth?
As you wish. Maybe, you can test feature, not a task. But testing of small peaces (task) is easier, than whole feature (if it possible). BUT sprint product should be tested as well.
+1 for the Elephant Carpaccio :-)
The goal is to understand the power of thin and vertical incremental developments :
Thin : the smallest code is written, the less code have to be changed for future stories
Vertical : each story should change any part of the n-tier
architecture
code (presentation, logic, data), so that each story delivers
immediate business value
I facilitated it and met his creator (Alistair Cockburn). This game/exercise is really interesting for teams facing customers with frequent change needs and small cash funds.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
As a school project, we are rolling out our initial set of user stories. Should a user story record the original idea from a user, without combining them or separate them?
For example, John added that "I want to post multiple choice questions.", and Mike added that "Except multiple questions, I want to post true/false questions." David added that "I want a confirmation box before I add questions"
Do you leave those 3 user stories as it is, or you want to combine John's and Mike's as "I want to post multiple choice and true/false questions." and within this new user story a detail like "show a conformation box before clicking the add buttion"?
What do you choose?
From User Stories Applied book (Mike Cohn), he talked about a "Good user story" which should have these characteristics:
I.N.V.E.S.T (Independent, Negotiable, Valuable, Estimable, Small, Testable)
Your question falls to "Independent" characteristic. The reason to combine OR separate is depending on how to make them "independent".
The reason to split/separate story cards
The story is bigger than one sprint
story combine with high and low priority sub stories
The reason to combine story card
When we see they have "dependency". And after combining, it's not gonna take more than 5 days to implement.
After combining and it would take more than 5 days, you should find another way to split the story.
About your example:
I want to post multiple choice questions.
I want to post true/false questions.
show a conformation box before clicking the add button
In my opinion, I will leave them as 3 stories because they look independent. Even for "confirmation box", you can implement just a box with add button that can show alert box for confirmation without any questions. Three of them look valuable and independent by themselves. Anyway, Product Owner or Customer is the one who can tell you if the stories are valuable for them or not. So, after splitting or combining, you have to confirm with Product Owner to make sure the stories are still correct.
I agree with Natty that I would leave them as independent stories. Just because they are related, does not mean they have the same business priority.
For example, it is entirely possible that the client decides that multiple choice questions are the highest priority, followed by true-false questions, but the confirmation box is so low on their priority scale that they would not want it implemented should budget not cover all stories in the backlog.
For this reason alone, I would keep them independent so that I could capture that business priority on each feature.
However, if I noticed that the client was always talking about them as "one story" and prioritizing them as a group, then I might consider making a combined story for prioritization purposes that would then be broken into multiple sub-stories for the development team to estimate and deliver.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When designing a back-end system, what granularity do you normally give your stories and tasks?
Most examples of creating stories and tasks usually center around a GUI application with the story being something the user can do (e.g. search for a book by the ISBN) and each task centered around enabling this GUI feature.
When designing a back-end system, i.e. one that doesn't have a user interface but is just a bunch of services talking to databases, middleware, etc. how do you come up with tasks and stories?
Basically, I try to keep the size of my User Stories in the area of 1 to 10 man-days to complete. That keeps me from passing what Mike Cohn calls "Epics" or "Themes" as user stories to the developers, and on the other size stopping my user-stories to be so specific as to imply the solution (they should be describing the problem, not how it should be solved).
As far as content goes, I make sure that my stories contain only business value - it never describes how I (should) satisfy the demand, nor does it "require" non-user-domain knowledge to understand.
Good example: As a content manager, I want all users to have to log in before writing a talk-back, in order to deny them the ability to spam.
Bad example: Add captcha to the web site.
Tasks, on the other hand, are steps towards solving the solution - they describe components & functionality that need to be added / modified. This is where an "Add Captcha" solution comes in. As far as size goes, I try to have each task's size be between 1/2 a day and 2-3 days of work.
Tasks also include a set of standard tasks that apply to each and every feature / requirement / problem / bug, such as:
Document
Write Test Cases
Manual Test
Write automated functional tests
etc.
Hope this helps,
Assaf.
As long as you have users, user stories can be around things users can do. If you are providing an API for other developers, then they are your users. Things will get more technical at that point (i.e. User can update Employee records)
I base the stories on the public interface of the classes. For task granularity I shoot for work effort of half a day to two days.
A user/ actor can be a system, not necessarily a person. Your services will have an API, expected input and results and a service level agreements (non-functional requirements). All of those can be specified in the story card.
Most importantly, your story card should specify acceptance criteria. Accpetance criteria will help drive the developers Test Deiven Development Unit Tests, the automated functional tests and the automated performance tests. If the acceptance criteria is meet, the card is accepted and approved by the product owner.