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.
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'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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm starting to add first user stories to my game backlog. My team has a rough idea of the game we want to create and we are ready to gather top level requirements. How do you do this? I mean, for example you can start with a mega epic (top level) that reads "As a publisher I want to create a game where player must feed a monster so that they spent a really fun time". Is this a correct starting point? Should we now split this epic into smaller user stories and split this user stories in smaller ones and finally in tasks? Is this "tree like" way of gathering requirements good or you usually use a "flatter" way?
Thanks in advance.
That is what we do. Start with epics that are fairly high level and the decompose them into more technical user stories. Generally we stop at one level, but sometimes a user story is just too big and it does need to be split into smaller chunks.
At the top level are epics, and right below are user stories, and that is it. It may help you to break down further as an exercise in decomposition - but building a massive tree of dependent stories might be a lot to track. We try and capture stakeholder needs AS epics (and yes, there can be some overlap, but that's ok.) We tend to want our user stories to be "lightweight requirements". The developer is free to create as many tasks as necessary to accomplish the story. And if the dev finds that there are just too many tasks, we go back and see if we can break the story up.
Our Product Owner manages a "feature backlog" which is just the fancy way of saying "epics". We link the feature stories to our team stories. There is not ONE top level epic, there are MANY top level epics representing feature needs. This way we can group features logically together for the sake of "releases".
You might want to take a look at a technique called "User Story Mapping", by Jeff Patton.
"As a publisher I want to create a game where player must feed a monster so that they spent a really fun time"
Something to keep in mind is that stories are written from the perspective of the users of the system. In the example you mention, it occurs to me that the Publisher is definitely a stakeholder for the project, but not a user (unless you're creating an app to generate games on the fly.)
Start by doing an analysis of users of your game. Probably "Player" will be the main role, but you can think of different kinds of players: advanced players vs. newbies, PC players vs game console players, players who want to explore vs just get through the game fast, etc. That will suggest you different features the game needs to support.
A good starting-point for writing good user stories is the book by Mike Cohn. There are also plenty of useful resources online how to write good user stories and how to work with the backlog as a Product Owner and how to involve the team to continuously keep the backlog in good shape so you can have effective sprint planning sessions, do reasonable forecasting of dates when features will be available etc.
It's always important to stay practical and experiment. Start with something and then inspect&adapt that so that you improve. This is the essence of any agile tool/framework.
If you want, start with the big epic and see how that goes.
Probably it's not worth having that epic, but rather discuss various things the player of he game can do that are more specific. These things are user stories, i.e. things that add user value throughout a whole product. A vertical slice of the system.
Some made-up examples to illustrate ideas around stories in a game setting:
Player that gets 100k points will get rewarded with a golden medallion.
Player must complete X and Y in order to open up the secret passage in Z.
Player can use portal to teleport to any level he chooses.
Yes you can see it as a tree or more and more specific stories that are children of other stories or epics. Practically, you only care about the leaves as that is the product of working together as the team and PO to work on backlog items during sprint planning or other sessions.
Experiment and start with something and improve from there.
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
We are just beginning to move from Waterfall to Agile. One of the few complaints about our new process is that our iteration planning meetings are taking too long, mostly because we are writing our story cards in the meeting itself, which was how the process was described to me.
One suggestion was that we write the story cards ahead of the meeting and ask everyone to review them before they come to the meeting as a potential time saver.
Is there an advantage to doing the stories during the meeting, vs. writing the story cards ahead of time and asking people to review them ahead of time, potentially saving everyone some time?
This is probably not an ideal question to ask as there's no real definitive answer. Responses are likely to be subjective.
Relating to my own experience, our team tends to get Stakeholders and Product Owners to add User stories in an adhoc fashion during our sprints to a projects product backlog (we work on a web application and are user driven in terms of functionality - we do have a roadmap, but we also adapt to feedback etc).
That way, when it comes time to do iteration planning we have a brief Product planning meeting with Stakeholders, Product Owner and project leads to discuss priority and adjust User Stories on our product backlog.
Once that's done, there's a subsequent Sprint Planning session with project teams that pluck off User Stories to work on in the sprint (picking off enough User Stories that we feel can be realistically achieved when gauged against our established velocity).
I'm sure other people do it differently, the key thing is to find something that works for you and your team.
which was how the process was described to me
You identified a problem in your process (too long planning meeting) and found out the root cause for it (writing story cards). The most sensible and agile thing to do is probably not to stick to "how the process was described" but to adapt accordingly, which means creating the cards in advance.
That said, from my personal experience, the sooner user stories are presented by the Product Owner to the team the better. Sprint Planning will probably be when story estimates are refined and little details are tackled, but it's generally better if the team did at least some exploration and estimation ahead and don't arrive at the meeting completely ignorant.
One of the most important purposes of User Stories is to serve as a conversation starter among developers and stakeholders. Based on my experience, it can save a lot of time to have one or two people review all of the existing requirements or requests and translate them into user stories.
But it is vital that the story cards get discussed, and that should take considerable time. Even though it seems like a lot of time that could be better spent on development, the reality is that, without discussion, development can easily go in the wrong direction. Asking people to review the cards ahead of the meeting often does not work - if they don't want to take time to discuss the cards during the meeting, they probably won't review the cards on their own time.
My advice: ask two people to work together on writing the user stories ahead of the meeting, but use the meeting to review and discuss each card.
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
Referring to this buddy question, I want to know how one can manage specs in Scrum process ? I'm facing this problem while assigning tasks to my team for the sprint. Needless to say - I'm new to Agile/Scrum.
Currently, we are using our own specs sheet to map StoryId to SpecId and vice versa. I'm getting the felling that Scrum is more about project management [getting things done on time] and you need a seperate process to manage specs and requirements.
How do we manage specs in a Scrum process ?
The short answer is, you don't.
The important question to ask yourself when writing these specs, is why do we do them? What is the value in the spec?
The value in the spec usually comes in communicating the ideas of the business with the development team. Scrum is designed to bring the business (in the form of the Product Owner) to the development team. By interacting with the team frequently (remember, individuals and interactions over processes and tools), and by seeing working software frequently, the business can work hand in hand with developers to produce software that solves business problems better than by trying to spec out the whole thing before you get to try it out.
This is how Agile projects do a better job of delivering the product the business wants instead of the product they requested.
That said, there are certain base criteria that need to be met. We can test for this, and as with any good tests, we can automate it.
Have a look at BDD and Cucumber. In addition to your User Story, it's good to have a basic set of conditions of satisfaction, preferably in the "Give/When/Then" format. These conditions are the minimum set of criteria for the story to be accepted as complete.
For example, "Given I am logged in, when I log out, then I am taken back to the home page".
If you're going to have acceptance criteria, you're going to want to automate it. The worst part of most specifications is they often end up out of date and collecting dust when the project is complete.
Also, you shouldn't be assigning tasks to the team. Scrum teams are self organizing and anyone should be able to grab any task they feel they can work on while respecting the priority of the stories. Swarming is a big part of the performance benefits of Scrum.
You may want to consider bringing in an outside coach to assist with your transition.
I think that the easiest way is to make the specifications a part of the user stories within the tasks, themselves. Clearly list the acceptance criteria in each one (or if your issue tracking software allows you, create them as first class work item types). Let the issue in whatever you use for work item tracking become the living document.
There are drawbacks, such as finding related issues as specs change over time, but this can usually be managed in the work item tracking tooling, assuming your can relate issues to each other.
The way that we do it is that we (actually a BA, not the developers) creates a sign-off deck for the product owner to review and we collaboratively create tasks off of that. If we cannot create a task, or there are open questions, we will go back to the product owner with those questions and update the deck. All of our decks are organized (in SharePoint) so that we can easily find them in the future.
For me the specs is in the user stories. We define the specs and the tasks duing out initial scrum meeting along with the product owner. The specs and tasks are just for the life time of the scrum iteration as everything might change in the next iteration(in the worst case but there will definitively be changes).
We usually keep track of the specifications and task on a spreadsheet just so that everybody know what they are working on. I have also tried a few software to do this and one of the most interesting ones I have come across is from [VersionOne][1] and also from [Rally][2].
But I still find that using a simple spreadsheet is the fastest and simplest solution.
As I understand SCRUM, it does not take care about specs management. You have to broke/map your specs or specs changes to stories and tasks separately. But you can have a task for this :).
There is a real tension between Scrum and other agile dev methodologies and spec writing. I think there are two big points of tension:
Because agile says everything should
be on an index card, that means you
have to have stuff planned out
enough to fit on an index card.
(E.g. you have to know how it's all
going to work.)
Some things don't make sense in
isolation (what's the use of an
upload file page without a manage
uploaded files page, for instance.)
You don't have to design the whole app all at once, but you have to have a vision of the whole app. Then, especially if you have a separation of designers and programmers, you do functional design for a sprint-sized chunk at a time. Those designs then have to be broken down to story-sized chunks.
This is a lot of up front functional design, and I think that's overlooked in a lot of the talk about agile methodologies. Perhaps some shops have the devs do more of the design. Also, I think it's a lot easier to use scrum/agile for making changes/bug fixes to existing apps rather than building new ones.
The thing I've found most helpful is to fight back on story size. A lot of organizations have gone crazy, saying stories need to be only a few hours. The original scrum book says 16 hours, I think, which is often large enough to fit an entire screen of a web app. So "implement manage my account" could be a story (as opposed to the hundreds-of-tiny-stories approach of "implement username", "implement password" etc.) Then reference your design doc for "Manage My Account" and make sure to have word-perfect screenshots/prototype/mockup so the dev can look at them and copy/paste the text directly into the code they're writing, and they know for sure which fields need to be there (or which links, or which pictures, or whatever).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.
EDIT: Additional Information:
We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.
EDIT: More insight/confusion perhaps:
I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.
Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.
If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.
Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.
Take an interation to rework or bug squash. That should give the BAs sometime to get ahead of the curve.
If, however, the problem is that the BAs need to see the previous requirements in the "wild" before making more requirements you have much bigger issues. :)
At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.
Update to respond to the questioneers Update
It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"
Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.
I take it that there is no sprint planning sessions from what you say.
Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:
Apart from having short sprints that is.
Well, a couple of things might help
- In the SCRUM process, there is the concept of Product Owner wchich is a Pig Role, this represents the customer. So you can invite the PLM or the client's main contact to your SCRUM's meeting. This will give your customer's some buy-in into your process and will get them to work "with" you on your goals
- Weekly builds to the client might help. So, the basic idea of the weekly drops is to show the customer "progress". So if for a few weeks there is no progress, this should raise the question "why?" and then you should be able to explain that it is for the lack of requirements finalization.
Hope this helps
the "user story" is a placeholder for a future conversation, so get in front of the customer and ask them; if that's the BA's job, light a fire ;-)
Your user stories are incomplete. 'Customize X screen' is a task, it doesn't describe any requirements or completion criteria. The user story should be something like 'Allow Nancy to see the related purchase orders for an item in inventory'. Then break that down into tasks during your sprint that you can work on.
Once the BAs have developed a workable user story then add it to your product backlog, prioritize it, and plan your sprints for the top backlog items. The BAs should be developing user stories and adding to your backlog independent of your sprints, and thus not blocking you. During a sprint the tasks are completed and the user story does not change. After releasing the customer provides feedback which goes into the product backlog as more user stories.
I see a few ways to handle this:
Option 1, Under SCRUM, you should have a Product Owner who is managing your product backlog, which is supposed to contain requests for features of the software. If the feature consists of something vague like 'Customize screen X' and you decide to add that to your sprint, then the sprint tasks should be concrete, decomposed tasks, and I would say one of those tasks has to be 'Define requirements for screen X'.
During the daily SCRUM, when you're asking your three questions of each team member, the developer who has that screen mod task will say "I'm blocked waiting for requirements from the BA.", and your scrum master does what they can to get that moving along.
option 2, in my opinion, is that items do not go into your product backlog until they're defined well enough to do at least some productive work on. We all know requirements change, but the point is that you're supposed to have enough to start with.
Easy.
Allow yourself to think outside of Scrum's strict rules, and get back to your lean roots:
http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/
http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Trust me, once you get that flow going, you'll never look back.
As it is said above, usually at the beginning of each sprint you should prioritize the existing backlog and pick some stories for the current sprint. If there is not enough user stories for the developers, you should shift developers to another project and let the product owner some time to create a decent (=large enough to feed some team) backlog for the project.