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
Are user stories (typically used in agile development or test driven development) the same thing as events in Edward Yourdon's structured analysis methodology?
Events and user stories are related but not identical. A Yourdon event is any stimulus to the system that requires the system to respond, so, for example, a tick from an external clock could be an event. That might require a response, eg, by incrementing a counter, but it wouldn't necessarily lead to a result with direct business value to the customer, so wouldn't be a valid user story or use case.
A user story is a pattern for briefly describing a business, technical or other type of need.
For example:
As a risk analyst I would like to add references to the application page so that we can store the references with the application, where the verifications team can then use them to help improve our risk rate in our underwriting.
Then in your user story you would decompose the story describing what tasks will be needed to complete the "would like" with a "done" check point being the "so that".
Mike Cohn has a good article on User Stories and the advantage of them http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements
As far as Edward Yourdon's structured analysis methodology, I have to admit I'm not extremely familiar with it so I cant answer that part of your question.
That´s right, user stories and use cases from UML are rewrites of Yourdon´s events. They are just a reinvention of the wheel.
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 2 years ago.
Improve this question
I am not sure when you would break story into stories or into tasks.
Let's say you have a story that talks about bringing down a service, and to do that you have to analyze and depreciate 5 api where each one takes one week
How would you do that ?
1) break story into 5 stories and this way every story is less than a sprint and can be owned by someone (but cant be demoed)
2) break a story into tasks but then multiple people is working on a single story and one story is lasting more than sprint
Other?
Thank you
Let's say you have a story that talks about bringing down a service
Why are you doing that? Who is going to benefit from it?
That information will help you to create the story associated with the work item.
As a [person that benefits from this work] I want the service brought down so that [reason]
Now, once you have defined the user story you can then add sub-tasks to it that describe how the work will be done. e.g.
Sub-task1 = deprecate API X
Sub-task2 = deprecate API Y
From my point of view, the so-called story should be an epic. The epic should be split in multiple stories, each one tackling the decommissioning of a different service.
It is also equally important to split the stories into sub-tasks because you will most probably identify "hidden flaws". It will also allow you to bring more transparency in the process of completing the story. If the stories are similar from the tasking perspective, you can define the first one as a template for the other ones.
You can view this topic from a different perspective: your purpose is to remove some services that hinder your progress. After you put down one service, you are closer to the desired outcome of taking all the services down. And of course, after each decommissioned server you bring more value for you, your team, or the customer.
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 a Product Owner creates a story, as well as acceptance criteria, what needs to happen if the team decides to break down the story? Should the team decide on the acceptance criteria, as long as the acceptance criteria of the main story are met?
What if the new stories that are created after breaking down the main story are purely technical?
The simple answer to this questions is you add acceptance criteria if you find them useful.
This is not a procedural thing. The idea of acceptance criteria came about because teams found them useful when it came to implementing stories. If you find acceptance criteria useful on stories that you have broken down from larger stories then use them.
What if the new stories that are created after breaking down the main story are purely technical?
Well then they are no longer stories, they are technical tasks.
A user story is a requirement described from the point of view of an end-user of the feature.
It is a common practice among Scrum teams to break stories down in to one or more technical tasks during sprint planning.
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
This may be a weird question and please bear with me, I am completely new into this.
I have a list of 20 requirements (use cases) which I received from my client. With him, I prioritized this list of requirements (1 highest 3 lowest). I wrote for every requirement a use case scenario (rather than user story). I also have a use case diagram and some technical designs (class diagram, database diagram).
Now, my plan is to separate this list of 20 requirements into 5 sprints. Each sprint lasts one week.
During every meeting with my client, I can show the product with 4 new use cases implemented. If one of them isn't finished, I move it to the next sprint and my client can request a change during this meeting. During this change, the specific use case diagram and classdiagram/database diagram may be changed.
Is this considered to be Agile? (Even though he gave me the full 20 requirements from the start of the project)
Agile is sort of a big tent, but I would not apply that label to the process you've described. You are describing lots of upfront design work and a full specs up front. The schedule assumes all the req take the same amount of time to implement, thought you acknowledge that it could slip.
The primary agile feature I see is the tight (weekly) feedback loop with client.
I recommend trying on http://pm.stackexchange.com.
This is not considered as Scrum:
- Schedule is prefixed (5 sprints).
- Velocity is prefixed (4 use cases/sprint).
- No scrum ceremony is followed as such.
- All requirements are given upfront.
Please refer - https://www.scrumalliance.org/why-scrum/core-scrum-values-roles
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
In Agile, should the 'user' in a user story always be the end-user or could it refer to different type of user? For example, is it acceptable to write something along the lines of, "As a developer I would like to have an interface to component B so that I can communicate with it from component A" or should it be restructured in terms of the benefit that such an interface would ultimately present to the end-user?
Chris,
The answer is "it depends on who the customer is". User stories need to be understandable and if possible written by your customer. If your customer is a developer of component A or B then it would make sense to you both.
However, if the customer doesn't immediately see the benefit of that I would ask "why" I was adding that interface and keep asking "why" until I get to an answer that the customer does understand. Then I'd write the user story so that the customer can understand what is being delivered.
Mike Cohen's book User Stories Applied is very good if you're looking for something more substantial to read.
http://www.amazon.co.uk/User-Stories-Applied-Development-Signature/dp/0321205685/ref=cm_rdp_product
Of course it is. If you are say writing a dll to develop with, then you are the end user of the dll...
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
Is it possible to or how should one use agile development processes (Scrum/XP) and write user stories in order to develop purely technical programming libraries (think Spring or a game engine for example)?
Yes, you can use agile to develop software that doesn't have a front end UI used by human users. First, because you don't have to use user stories to be agile. Even Scrum doesn't prescribe that the backlog has to be expressed in user stories. It just says there should be a backlog, it should have one order of priority and items on top of it should be small enough to fit into one sprint. They can be expressed in any way that is understandable to both the Product Owner and the team.
But, second, you can write user stories for libraries too. You just think of potential pieces of software as roles - or even create imaginary personas that could be using this library directly. "As a text editor I can call this library to encode strings in Base64" would be an off the bat example of the former technique.
To sum it all up: any type of software can be developed with agile, user stories are not key to agile - they are just one pretty useful technique frequently used by agile teams.
The same as you do for business-based requirements, except the reqs are prioritized by the API consumers/technical people?
If you're talking about Spring or Game engine, you still have a customer/product owner point of view to write your stories from..
That's you'd talk about your API, how other developers will use interfaces or what is exposed of your black-box
They are many component vendors that use Scrum to manage the development of their libraries.
I can tell you two of the StackOverflow.com sponsors are using it actively.