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
I'm currently busy writing business rules and user stories for a project I'm on. For a few stories there should be default behaviours like the following.
The application handles orders for representatives. When a order is placed for a certain region, it should pick a default warehouse (some regions have their own warehouses).
I'm wondering how you can define these behaviours for user stories. Are these considered business rules?
'Sounds to me like you just did an excellent job.
And yes - this is very definitely the kind of detail that absolutely BELONGS in a use case.
IMHO...
I'm wondering how you can define these behaviours for user stories.
They're expectations of the user that you're making explicit.
Are these considered business rules?
Yes.
The tricky part is this.
Story 1: The order is handled manually and a user picks the warehouse. This is front-and-center of everyone's mind. They talk about this at length.
Story 2: The order is handled automatically and a warehouse is picked by the system. This is assumed. What more important is that there's no actual user interaction here. It just "happens" without an actor seeing it or interacting with it. Since there's no interaction, it's not a very good user story. It doesn't lead to a fancy screen and the normal artifacts that go along with a proper user story where a user has interaction with the system.
When "automatic" or "default" things happen, the user story becomes a kind of degenerate case where it seems like less work needs to be done because there's no screens or pages or forms or interaction.
However, when "automatic" or "default" things happen some user somewhere actually does care and actually does need to see that it did happen. Even if it happens in bulk. Somewhere else, there's a variation on user story 2.
Story 3: Someone, somewhere, checks the counts and totals for the default warehouse assignments, including manual and defaults. Here, the default warehouse assignment is seen by an actor who is interacting with the system.
Automatic or default behaviors often highlight the need for review or audit or overview stories to be sure the automatic stuff really happened correctly.
From my point of view the default behavior is the main user stories and any alternative is another user stories.
So Yes you have to add this user story.
Thanks
M.Radwan
Related
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 2 years ago.
Improve this question
I'm stuck with one small part of my project. The main idea of the project is:
There are a customer, a bank and a shop as actors.
A customer wants to make an order but before he/she does it, the bank needs to check if the customer is on a blacklist.
If he/she is not, the bank puts the customer's and shop's details in a file and at the same time sends a credit note to the shop.
The next part makes me confused:
Customer personal information should
be protected following the General Data Protection Regulation
(General Data Protection Regulation - GDPR).
How can I implement this part in my diagram?
First of all, the use-case diagram is about user-goals. Use-case diagrams do not describe an order of what happens. So "before", "after", "at the same time" do have no effect on the diagram. If you're interested in the sequence of events, you should consider an activity diagram (i.e. flow of actions) or a sequence diagram (scenario).
So what I understand from your narrative is that:
actor User, in relation with the actor Shop (but is it really an actor?) has a use-case Order something
actor Shop (but is it really an acor or does your system ensure this?), in relation with the actor Bank has a use-case Control payment (make sure that the customer is not a known terrorist and ensure also that the customer has the money needed, probably in relation with the customer's bank).
The information you provide si probably very incomplete, so I leave you as an exercise the precise design of the use-case.
THe GDPR requirements do not influence at all your use-case model: it does not change the gloals, and it does not change the involved parties.
What might be influenced is the activity diagram and the class diagram:
the GDPR requires among others a privacy by design. So you cannot provide to the bank details that they do not need to know (e.g. what the customer purchased).
the shop is not allowed to get the blacklist either! The control of the blacklist is done by banks, so that the shop owner will not be tempted to refuse a sale just because of some similar naming.
THe only thing that could eventually influence your process, is the consent. Giving the consent and managing privacy could be a separate use-case, since its's a right given by the law and that some users want to exert. For example that the customer consents that his/her data is provided to another party. But in your case, it doesn't seem a big deal: in the case of a payment by the bank, this seems an obligation and the blacklist is in general a legal obligation not related to the the consent. So it will not impact your design, but only the wording of your privacy statement. So it seems that for you, GDPR will be more a legal matter to check with a legal expert, than an engineering one.
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 1 year ago.
Improve this question
I am working on an open-source project which shows how to develop software iteratively using test-driven development and some ideas from domain-driven design. I know what I would do, however my formal skills (especially regarding UML) are a little bit rusty.
Below I am going to post my first steps with the diagrams and the explanations I would give to my readers.
I have the following questions:
The last step ends with the question But what will stich together these components?. How to show the reader the way in UML terms, while not skipping anything in the train of thought? What I plan to do is to let each component provide an Environment class. For the purpose of testing, a TestingEnvironment will gather all those environments and inject the right callbacks into the World. But which types of UML diagrams to use for showing my train of thought, and in which order? My problem is, somehow, that I know what I want to do, but I can't rationalize it to myself why I want to do it that way - I guess it has gotten a part of me to the point I don't make such decisions consciously any more.
What mistakes have I done so far, how to fix them, and most importantly: WHY?
Step 1
(0001_user_commands_use_cases.pdf)
(0002_user_commands_use_cases.pdf)
User Use Cases - Analysis
We are starting with an use case diagram (0001_user_commands_use_cases.pdf) as
part of the preliminary analysis stage. This diagram should only help us
understand what our client wants. These use cases may change over time, but
never the less, they help us understand the system we are going to develop.
Please follow the arrows while reading the following explanations.
The role the user plays when interacting first with our system will be Guest.
The Guest sends to the system some registration data, which we process.
In the diagram, we are describing what happens from a logistic point of view,
from the perspective of the client for which we write the application. We are
not referring yet to classes or objects, or the concrete workflow, which may
end up being quite different.
We are also not dealing with errors, because that would only add more
background noise to the idea - and because error handling does not add business
value to the system. Of course, a system has to be robust to errors, but keep
in mind that we're now just making the analysis - not the design of the system.
Logistically speaking, after the Guest has sent us the registration data, there
is a Registered User. A registered user can send us the login data, so that he
becomes an Authenticated User.
Following the diagram, we can see how only an Authenticated User can send to us
a request to log out of the system, thus becoming a Deauthenticated User.
Why a Deauthenticated User, and not a Guest back again? Basically, it comes
down to us not being able to foresee the future. We really have no idea how the
client will want us to extend the system - nor does he himself! Beside that,
the two roles, a Guest which we know nothing about, and a user which has just
deauthenticated, which we do know something about, are really different things.
Of course it may be that the Deauthenticated User will exist in our application
only for a very short period of time, or it may be that it's created for the
sole purpose of being destroyed back again, without being looked at by any
other subsystem of our ERP - but still I cannot stress it enough: logistically,
the role of a Deauthenticated User stands on its own.
The second diagram (0002_user_commands_use_cases.pdf) contains all the
information of the first diagram, with some added items. If you follow the
green arrows, you will see that the process is the same.
In the first diagram we notice how all three things done by the ERP system are
some kind of generalizations of a process. We have introduced this new generic
process in the second diagram as "Process Data".
Another element we have added in the second diagram is a generalization of the
three "Sending Data" elements. We are not sure how this will materialize in the
next stage (designing the system), but it looks like there's a generalization
there which may, in the end, make the system easier to maintain and extend.
We always seek new generalizations and abstractions because they have this nice
property of making the code maintainable and extendable.
Conclusion
----------
In our design, the ERP will do one central thing, "Process Data", data which
will come in in a standardized way, represented in our second diagram by the
"Send Data" use case.
We don't know how we will design these things yet, until now we have only
thought about the logistics, since we are doing just the analysis.
In the next commit, we are going to look closer at the application domain, in
order to better see the relations between all these notions and to enable us to
come up with a cohesive design.
Step 2
A rough overview of the components in the context of the application domain
Before looking at the diagram, let me first explain the thoughts I had prior to
coming up with this diagram.
We are going to design an ERP. What is this all about, and where lies the
business value in it?
We are supposedly making the product for a company which makes money by sending
products back and forth. This is the core domain of the application.
The basic idea is that a product P is moved from point A to point B, and in
this process, the company makes money.
The application will allow the company to make money by both being good at
organizing the workflow, and by making an existing workflow cheaper.
Let's say a product can be delivered to point C by taking the route A -> B ->
C, or the route A -> D -> C. The ERP must be capable of deciding which one is
better (in terms of money or time), and must manage the workflow it chooses.
So the whole point is supporting the movement of products around. Around what?
Around the world.
For this reason, let's first draw our first component: the World.
In a real project, I would continue by adding a Product component. I've chosen
not to yet, because this project is an educational one in nature, and I wanted
to get across new ideas about the architecture. If I had focused on the
products, I think there would be too much noise for the type of audience this
project is aimed at, a noise which would make the process of creating the
architecture and the architecture itself harder to understand.
We will introduce a Product component later, when the reader will feel at ease
with the architecture which, at that point, he will feel familiar with.
Instead of focusing on Products, we are going to focus on Users. This is,
incidentally, also the subject of the use cases we have drawn in the previous
commit. I think that any reader can relate to the concept of User.
So let's draw that component, the User.
Architecturally speaking, it's not that much of a difference between an User
and a Product. Instead of having Products moving around, we will have (for
now), users who live in the World and take different roles while interacting
with our system.
In the previous commit, we have concluded that there would be a standard way of
passing in data from the User to the system.
In terms of DDD (Domain-Driven Design), the data that gets into the system is
packed up as a Command. Since it looks like a good name, let's make a port of
the World component called Command Hub which will be used to receive and
process Commands from the outside.
Conceptually, the Command Hub will provide a Command Interface which any other
component can implement in order to send commands to the Hub, if it needs to.
We also want to make the components decoupled and thus reusable in different
types of applications, or to be able to combine them. This is achieved by
making an event-driven architecture.
For this reason, let's give the World component an Event Hub, which will
provide an Event interface.
But what will stich together these components?
This question is so pressing, because it's so central to our architecture, that
we will have to further investigate it.
This is not an asnwer, just a comment that would not fit into the comment box
(1) if you want to "teach your readers" something you can't do yourself, it is strange approach. Show your readers the way which works for you. Show the way "your train of thoughs runs", show the the mental images you saw in your mind, paper/pencil/photo in whatever visualization language you use
(2) you're skipping the uml-diagrams: UML 2.5 Behavior Diagrams as not useful? Even the uml-diagrams.org: UML Interaction Overview Diagrams not useful?
(3) this question looks like too broad(long) perhaps opinion-based and perhaps off-topic much more suitable for https://softwareengineering.stackexchange.com/help/on-topic
(4) for the recommended modeling workflow look at
(4.1) Cangnus's sequence diagramming comment in Stack Overflow: sequence diagram for books exchange
(4.2) BobRodes's use case scenario comment in Stack Overflow: Formal language for UML sequence diagrams
(4.3) Scott W. Ambler's Agile Modeling: Where Do I Start? for what when how and why Agile Modeling Best Practices
to name just a few
In conclusion of this my long comment, I don't see any mistakes you did. If this is description of how Test-driven Development and Domain-driven design works for you so well that you even use it subconsciously then it is just fine and ok. Being a good teach is not an easy task, good luck
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
The Product owners have specific requirements around how the Product should enable the users in a complex business process workflow (approvals and what not). The easiest way to document the requirement is in the form of a process diagram/flowchart.
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
Option 1
Have generic user stories that encompass the workflow, and attach the flowchart diagram as a supporting document. e.g. As an author, I want to be able to submit my article for approval process so that it will get published.
Pros
it's easier for people to understand and digest - rather than reading 10-20 user stories.
Cons
it becomes an epic
Option 2 Break down the complex flowchart into its own user stories. e.g.
As an author, I want to be able to submit my article.
As an editor, I would like to get notified when an article has been submitted so that I can review it.
As an editor, I need to approve an article
As an editor, I would like to be able to request for more information
...
Pros
pure Scrum. easy to prioritize/estimate/plan
Cons
As you can see even a short business process workflow will easily explode into a lot of user stories.
I agree with pma_. Do what makes sense. In this case, you have some great looking user stories.
"As an editor, I would like to get notified when an article has been submitted so that I can review it."
If you have a ton of these, then perhaps they are too small. They would all be 1-2hrs. That's probably not a good thing to have. In that case, try grouping them. Perhaps
"As an editor, I want to be able to manage articles". That would include several of the ones you have already.
Keep in mind the goals of user stories...
Track items on a burndown chart
Deliver fully functional work (not an unusable subset of work)
Have estimatable portions
If you can achieve those goals, you're good. If not, try again.
Oh, and one last thing - keep the flow diagram, don't throw it out in favor of stories. But supplement the stories with it.
If this business workflow is like most business workflows, each of those steps will have a significant number of rules. Those rules should map into acceptance criteria for those stories and ideally, automated tests to prove that the code works as intended. Because of the potential for a lot of acceptance criteria, I would lean towards the second option.
I tend to go towards Features/Epics early on with the core end user/stakeholder value-adding functionality, such as in your example to "Publish an article so that the subscribers can get the latest news". Then once the Feature is getting closer to implementation I'll split it into implementation sized stories if needed.
Most non-trivial business workflows benefit from being split up during implementation so that they can be continiously deployed and verified in order to get early feedback from the stakeholders. The big con of having everything as one big bang implementation is late validation. I think that having early feedback is outweighing the increased administrative burden of handling multiple stories.
A tip on how to split epics into stories: Lasse Koskela has a great writeup on how to split stories in different ways.
For me all agile is about using common sense. I this case you have perfect desing so just implement one and don't look for unecessary things.
We're currently building a business process based content management system. We split our processes into stories as per your 2nd option.
But, of course, we keep the flow diagram handy. In fact, we print it out and stick it to the wall. We even keep every old version of it so we've our own paper based version control stuck to our wall (in addition to using git for the electronic version ;-) )
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
The two options that you have mentioned are not really options, they are sequential stages, IMHO. During Agile Requirements Gathering or Product Planning the first step is to create EPIC stories. After you have those Epics, you need to break them down into smaller chunks.
Without the EPICs you will most likely to run into the issue of creating random stories without getting a grasp on the sense of belonging of a story. You can in a way create a hierarchy in User Stories. Without understanding that, everything is just random, hence it makes it tougher to wrap your head around or manage the stories as a PO.
Offcourse there is much more to all this than what I mentioned in the above paragraph. That's why probably you need an experienced Scrum Coach or do a lot of diligent reading/implementing on Agile Planning and User Story writing.
Hope this makes sense. I would suggest reading Agile Estimating and Planning by Mike Cohn for anyone who even remotely thinks of taking up a PO role. Best of Luck!
Workflows are an interesting entry to writing user stories and epics, but user stories don't map to work flows, they map to business capabilities. So you are incorporating some fallacious thinking from the start in this question. Workflows are a good tool for the conversation, but will live independently of workflow as they are about functionality, not timing. Timing lives in the business rules.
On that note, business rules are not Acceptance Criteria, they are the connection between Acceptance Criteria, which are features that can be demonstrated by a product owner, and Test Cases. Again, Acceptance Criteria are about features, not behavior. Behavior lives in the business rules.
For instance I might have User Story for an ATM that says "As a user, I can check my account balance." And the Acceptance Criteria could be "If I am overdrafted, I get an alert notice." The rules for what constitutes an over draft (I had $1000 in my account and deposited my $2500 pay check, but that won't clear before my $1500 mortgage payment, etc.) are not acceptance criteria. They are business rules whose execution results in the demonstrable action of the Acceptance Criteria. Note, that this user story could be captured through a workflow analysis, but might live in many workflows (or none).
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
If I divide development of a particular feature into multiple stories:
First one for a high level design of the feature,
Based on first story I create other stories to develop the different stand-alone pieces that compose the feature,
Does it mean I'm doing waterfall?
Furthermore - if I divide development of the previously identified stand-alone pieces into design and implementation.
Would that mean that I'm doing waterfall?
Note: I am big time Scrum novice.
There is no such thing as design and implementation stories, User Stories should provide some level of end-to-end functionality to the user (i.e. delivering customer value).
The fact that you are mixing the terms stories and features doesn't help to communicate but what you're describing sounds actually like tasks (Sprint Backlog level), not user stories (Product Backlog level).
And if they are not tasks, then they are very bad stories. Maybe the "functionality" is too big and you should put the story on diet but what I see here is a typical story smell.
If you are new to User Stories, I strongly recommend to use the regular template (As a <type of user>, I want <some goal> so that <some reason>) and also to follow the INVEST model. This will really help you to avoid pitfalls like the one of your question.
Back to the real question (Am I doing waterfall?): there is nothing wrong with doing so design inside a Sprint (as a task of a story). But if your whole story is about design, you're not really doing Scrum, you are supposed to deliver a demonstrable end-to-end increment at the end of the Sprint.
Scrum stories tend to be about "business value":
Business value is a concept that describes the relative worth of any development effort to the business. Business value is often unquantifiable, but often relates to money.
You can think of business value as something that could still be sold if the project was stopped.
If you write a story to create: "a high level design of the feature", what you would produce by implementing that story isn't something that the business can sell. It's not something customers can try, buy, use. In effect, the business value of that story is zero.
You might have better luck thinking about stories "vertically". "Vertical slices" are minimal features that cover your entire technology stack. For example: "A user should be able to enter their name in a text box, click a button, and be shown their record in the database." It's not, by itself, especially useful, but it is more valuable than a feature design.
No, you're not. The sub tasks can be added to the backlog (presumably with roughly equal priority so they come out around the same time) and then the super-task would be to integrate/test/etc the separate components.
It sounds like a valid way to breakdown a large component to me. Just make sure you size up the different chunks appropriately. I've found 4-16 hour chunks work best. Giving 40 hours for a task means they'll do 2 hours of work until Friday when they cram the other 32 in (along with lots of bugs).
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 begging a new project (oh, how I love the fresh taste of a new project!) and we are just starting to design it. In short: The application is a UI that will enable users to model an execution flow (a Visio like drag & drop interface). So our greatest concern is usability and features that will help the users model fast and clearly the execution flow.
Our established methodology makes extensive use of Use Cases in order to create a harmonious view of the application between the programmers and users. This is a business concern, really: I'd prefer to use an Agile Method with User Stories rather than User Cases, but we need to define a clear scope to sell the product to our clients.
However, Use Cases have a number of flaws, most of which are related to the fact that they include technical details, like UI, etc, as can be seem here. But, since we can't use User Stories and a fully interactive design, I've decided that we compromise: I will be using Essential Use Cases in order to hide those details.
Now I have another problem: it's essential (no pun intended) to have a clear description of UI interaction, so, how should I document it? In other words, how do I specify a application through the use of Essential Use Cases where the UI interaction is vital to it?
I can see some alternatives:
Abandon the use of Use Cases since they don't correctly represent the problem
Do not include interface descriptions in the use case, but create another documentation (Story Boards) and link then to the Essential Use Cases
Include UI interaction description to the Essential Use Cases, since they are part of the business rules in the perspective of the users and the application itself
Getting user feedback with UI prototypes is essential to creating a user interface that your user community will understand and be productive with. The best way to do this IMO is with paper prototyping. Your use cases can drive the initial creation of these prototypes, and the user interaction sessions with your clients can refine the UI design.
If you prefer electronic prototypes, you can use something like PowerPoint to rapidly prototype them.
See also http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html and http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html
First gather information about the users' workflow and goals. This is best done by physically going to see how the users are doing their work today (for example using contextual inquiry). Document those goals as goal-based use cases (see the link below), which contain only the goal - they should not contain any details of how the system will be used, because those details are what we are just starting to design based on the use cases.
Based on the use cases, create a quick paper prototype of the UI, and try step-by-step that how the users would reach their goals using the prototyped system. If the use cases can not be executed well enough with the UI prototype, keep on improving it until all use cases are supported. Show the prototype to the users and use usability testing and other techniques to find out problems with the UI.
When the UI design is good enough (~85% ready - some fine details are best tweaked after implementation), you can document it for example by taking picture sequences of the prototype, which show how the use cases can be executed with the system. But communicating the UI design to the programmers is best done face-to-face, by showing manually how the prototype works and answering their questions. Don't just "throw the documentation over a wall", but follow through to see how it is implemented and test whether the implementation matches what was designed.
See the longer process description at http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf