I have a set of User Stories and I have a set of business rules (primarily laws binding my requirements to be compliant). In Agile SDLC I'm not sure where these "rules" are attached to my user stories.
For example, a user story like:
As a doctor I want to add patient information in order to create a new patient file.
And a rule like:
The following information must be entered in the record of each patient:
(a) patient:
(i) name and given name;
(ii) address;
(iii) date of birth; and
(iv) sex;
These two clearly come together, but how can I link them? As test acceptance definitions in my user story? Another user story?
There are a few different ways I've seen this handled:
An artifact is created to hold the business rule and is stored in some central repository of all the rules so this is known throughout the development team and a storehouse of knowledge is maintained. This can get ugly as there can be hundreds of rules within just a few years of building out an application.
The rules may be put onto separate cards within the user story. Thus, while the user story is that one line, there may be 6-8 cards that make up all the tasks for that story to be completed. For example, there has to be a new patient form created, validation on the form, etc. Thus, it isn't hard to see this crop up down the line on a card as a way to track the requirement that way. This is the most natural to my mind though this isn't where the specific list is going to be 100% written down either as the card could be "ensure some fields on the form are mandatory."
There isn't an explicit link but rather the rule is something for QA or a BA to note for the user to verify that the form does enforce this rule. This is similar to one but the question is what is the responsibility of the developer in this. In this case, it is something for QA to track rather than developers possibly.
The user story is intended to start a discussion, not be a comprehensive list of the requirements. The rule is something that should come up when the developer discusses with the user what does it take to create a new patient file to my mind.
I like the idea of hanging on to cards for a few sprints after the story was done, but I do see the point that the cards will ultimately be destroyed. At the same time, there should be code somewhere that implements the rules in its proper area. To use the example you posted, it may be that in a few places the list of required fields would be noticed as there is the UI layer that has to show the fields and probably an error message but also there should be some Business Logic Layer that has this logic to see that some fields were specifically completed before trying to create a new patient file. The system being built will also house the rules in some form or other, too.
As acceptance criteria. After all these are rules that can be executed as tests. Definitely not new stories, that would just be wrong as there is no deliverable goal.
Related
I know in waterfall, they are gathered and documented at an early stage of SDLC, I believe very first stage. Therefore, they are captured and documented before development and testing even starts.
But I am confused how is that done in Agile?
If I understand correctly, user stories should be written with acceptance criteria which capture non-functional requirements. But in Agile, we pick project, create it, and start working on it right away.
So, my guess is that someone (perhaps product owner) goes through user stories and collects acceptance criteria into a formatted document which then becomes Non-Functional-Requirements document?
First, to answer your question, I must be clear that no Agile frameworks or methodologies attempt to define everything that a team might need to do (especially Scrum) so there is nothing wrong with adding extra artifacts or practices that the team finds useful as long as they aren't contradicting a defined practice.
There are a few places I typically see non-functional requirements recorded. Here are a few of the most common ones:
Definition of Done
The definition of done contains standards for quality that should be applied across all backlog items that come through. Often times this includes things like "n% unit test coverage of code", "code and configuration changes have been peer reviewed", and "all automated regression tests have been run and pass". I've sometimes seen broader non-functional requirements like "no changes cause the application load time to exceed X ms".
Architectural Design Documents
You can still have these in Agile. Rather than establishing the finished architecture at the beginning of the project, they introduce constraints that the architecture has to stay within. As the project progresses and architectural decisions are made or changed, these documents are updated to reflect that information. Examples of constraints may include "System X is considered to be the authoritative source of customer personal data" or "Details needed for payment processing should never be available to a public-facing server in order to reduce attack opportunities on that data."
Product Chartering
Depending on the project, "starting right away" is a bit fluid. On very large projects or products, it is not uncommon to take a few days (in my experience, 1 - 3 is a good number) to charter the project. This would include identifying personas, making sure business stakeholders and team members have a shared understanding of the vision, talk through some expected user experiences and problems at a high level, etc. It is very common that non-functional needs come out here and should be recorded either in the DoD, existing architectural documents, or in some cases, in backlog items. One good example of this happening is something called a trade-off matrix. When building a tradeoff matrix, we talk about constraints on the project like performance, adaptability, feature set, budget, time, etc. We identify one as a primary constraint, two as secondary, and all others are considered tertiary. This isn't a hard-and-fast rule, but it establishes an general understanding of how trade-offs on non-functional needs will be decided in the work.
Backlog Items
Ok, last one. Not all backlog items have to be User Stories. If you have an actionable non-functional requirement (set up a server, reconfigure a firewall, team needs to convert to a new version of the IDE) there is nothing that stops you from creating a backlog item for this. It isn't a User Story, but that's ok. I will warn that most teams find a correlation between the number of items in the backlog that are User Stories and their ability to effectively deliver value and adapt to changes along the way, so don't get carries away. But I'd rather see a team put in a non-US in their backlog than try to pass off those things as user stories like "As a firewall, I want to be updated, so we don't get h#XX0rD" <- real backlog item I saw.
As a final note: remember that in Agile, we strive to adapt to change, so don't worry about getting the DoD or architectural document perfect the first time. It can change as you learn more.
As my ubiquitous language I have some phrases like :
Feature : Display A Post
In order to be able to check mistakes in a post
As an admin or customer
I want to be able to view the post
Scenario : Display Post
When : I select a post
Then : the post should be viewed
Is that a right user story? Such scenarios may have some minimal differences at UI level. Should I violate the DRY principle and repeat the feature for another role?
Different users may need different requirements over time, and I think this is the reason we usually write user stories per the user role.So should I be worry about how the requirements may change over time for different roles or I can leave a single user story (and the same test code,production code, databse ...) with multiple roles and refactor when their requirements forced me to separate them ?
I am not sure what your problem here and will try to guess. So first, your first three lines is just a description and not real steps. This enables adding custom text that will not run.
As to your other 2 steps, it is very hard to say whether they are good or not. As you might have already noticed, you are not bound by Cucumber to have a specific scenario flow. Cucumber gives you the freedom to design and write your code the way it makes more sense to YOU and YOUR business logic.
Saying that, I see no issue in repeating similar steps to test another role. In order to make the feature file a bit more DRY you can use the Scenario Outline option. It might look something like this:
Scenario Outline: Display Post as <role>
When I select a post as <role>
Then the post should be viewed
Examples:
|role |
|role1|
|role2|
In this case, two scenarios run one after another while rolevalue changes according to the Examples list.
Now, in regards to your possible changes in future. You can't always predict what will happen in future and unless continuously changing current requirements is a normal practice for you or your team, I wouldn't worry too much about this. If sometime in future current scenarios will become obsolete, you will review them and rewrite them or add new ones accordingly.
If multiple roles are required in a feature, then that means it is an epic, not a feature. It is a must to break down each feature so it only has one role, and it can deliver a single value to a single group of users.
I think the problem here is your language which needs refinement to clarify what you want to do here and why its important.
It seems to me that as an admin looking to fix mistakes in a post that what I need to is to be able to change a post.
A similar thing applies for the customer (should that be author?). If you explore what they will do when a post has been authored with a mistake then you will probably find that different roles interact in different ways. You'll start to ask questions about what happens if the customer and the admin make fixes, and how the customer responds when the admin makes a fix that the customer doesn't like and all sorts of other scenarios.
If you do this you'll probably find that most of your duplication goes away, and you'll learn lots about the differences between customer and admin behaviour in this particular context.
I'm trying to write a scenario :
As a user
......
Scenario: Breaking a rule
Given:I'm an active user
When: I break the rule 'X'
Then: I should be added to rule breakers' list
Butrule breakers' list is defined in another story.
So this story is no more independent.
We can change the Then phrase to this:
Then: The rule 'X' should be breaked by me
But the behavior of my scenario doesn't seem clear enough.
More examples:
Scenario: Registration
.....
Then: I should be loged in
(While login belongs to another scenario)vs
Then: I should be registered
And the real problem comes to the action when navigation is something your stakeholders care about.
My question:
How can I have an independent scenarios which are clearer in situations like that?
If the rule breaker's list is defined elsewhere, it's part of the state in which the scenario starts, so it's a "given".
Your scenario should resemble something like:
As a user
......
Scenario: Breaking a rule
Given:I'm an active user
And: I'm not in the rule breakers' list <- Add another given
When: I break the rule 'X'
Then: I should be added to rule breakers' list
The extra "given" can reuse the same code as the other scenario, if that's useful. Alternatively, you can use a shortcut, like putting data directly into the database rather than going through the UI. It's fine for this scenario to have no knowledge of how that list comes into being, as long as there's an example of that somewhere else.
What is a "user story scenario"? User stories come and go they are not much more than a piece of paper and some discussion. After the user story is finished, it has unsignificant relevance. However, your gherkins are there to stay as automated tests and living documentation. After the user story is finished, you can deliver a new function. What is that function? Your gherkin should describe exactly that and nothing more.
In your example: ok, there might be some plans that we are also going to keep a list of rule-breakers, but let's concentrate first on the immediate user story and forget about such a list. That list might be a separate user story later on or it may never even happen. So the question is: what immediate value has my current user story, what is the functionality that the users will see. If it's just some feedback to the user along some rules, than that is what my gherkins should reflect: Given some preconditions When I'm breaking rule 'X' Than I should receive feedback this or that way.
If it is difficult to come up with sensible gherkin scenarios, chances are high that you have split up your user stories inappropriately (which BTW is not a problem, but something best found out as early as possible - which is the very reason you are using bdd.)
I've been a JIRA and Bugzilla admin in past jobs, and have quite often had users ask for the ability to have more than one assignee per issue.
I know this is possible in JIRA, but to my mind it never makes sense; an issue should represent a piece of work, and only one person can do a piece of work (at least in software, I've never used an issue tracker for a 2-man bobsled team ;-)) A large piece of work will obviously involve more than one person, but I think in that case it should be split into subtasks to allow for accurate status reporting.
Does anyone have any use cases where it's valid to have multiple assignees ?
The Assignee field means many things to many people. A better name might be "Responsible User". There are three cases I discuss with my clients:
A. number of assignees = 0
JIRA has an Allow Unassigned issues option but I discourage use of that because if a work item isn't owned by anyone it tends to be ignored by everyone.
B. number of assignees = 1
The default case
C. number of assignees > 1
Who is responsible for the work item represented by the issue? The best case I've seen for this is that when an issue can be handled by any one person in a team, so before triage the issue is assigned to everyone in that team. I think a better approach is to create a JIRA user with an email address that sends to the whole team, and assign it to that user. Then a member of the team can have the issue assigned to them in particular.
Changing the one assignee case has the history recorded in the History tab. Nothing is lost in that case.
I'll often have a story / feature that can be split across multiple developers. They will have individually assigned subtasks but it would make sense to assign the parent to all involved, unless there's a lead developer. I wasn't actually aware that I could do multiple assignments, so thanks for the tip!
The other case I can think of is pair programming.
I hit upon this question while looking for solutions to doing this. Since I want to do this, I'm guessing my use case counts as an answer to your question: I only really want one assignee in the sense of someone currently working on a problem, but I want to track the whole lifecycle of an issue. For us, that can mean:
A support person receives a report from a customer, creates an issue
An issue-wrangler reviews the issue to make sure it's valid, not duplicated, has all appropriate details, etc.
A developer implements/fixes the issue
A tester performs whatever tests are appropriate (in our case, mostly extending our automated testsuite to additionally test the feature/fix)
An operations person rolls out the new version to a test environment
A support person informs the customer, who does his own tests with the new version in the test environment
An operations person rolls out the new version to production
Not all issues necessarily go through all steps. Some issues have more steps (e.g. a code review between step 3 and 4). Many issues will also move backwards among the steps (developer needs more information, we go from step 3 to 1 or 2; tester spots a problem, we go from 4 to 3).
At each stage, only one person is actually responsible for whatever's got to be done. Nevertheless, there are a whole bunch of people who are associated with the issue. Tracking systems we've used are happy to offer easy changes to previous owners of the issue (shown as a list), but I'd ideally like to go a step further, with the owner automatically reverting to the correct prior owner depending on the issue's status. At step 6, the original support person from step 1 should ideally contact the customer. At step 7, the ops person from step 5 would ideally be the assignee.
In other words, while I don't want multiple assignees for a given step, I do want there to be a "support assignee", a "developer assignee", a "testing assignee", etc.
We can do this with subtasks and we can do it by manually selecting previous owners when changing statuses, but neither is ideal and I think the situation above is one where multiple assignees would make sense.
In my company, we have a similar workflow to Nikhil. We work in a scrum model, with developers, testers and a technical writer on each team.
The workflow of a development task is
Development -> Developer review -> QA testing -> PO Acceptance -> Done
The workflow of a QA task is
QA writes test case / automated test -> QA review -> Done
We had a tool which JIRA replaced that allowed us to assign multiple people to a task, which we found very useful for our workflow. On a QA task, I could easily see if the other tester on my team had already done work and I needed to do the next step.
Without this, I am finding it difficult to quickly identify tasks written by the other tester on my scrum team which are ready for me to review (versus the ones I wrote which they need to review).
So many people have asked for the ability to have multiple assignees since at least 2007. They have varying, valid use cases. I was disappointed that the JIRA development team unilaterally said they won't implement this and would ask them to reconsider.
https://jira.atlassian.com/browse/JRA-12841
While pair-group working (pair programming etc..) it would be nice to assign both persons to the issue.
Tasks move through different steps through development (example: Development, review, testing). Different persons can be responsible for each step. Even though the task may be in review or testing, the reviewer will have stuff fore the developer to fix. Having different roles to assign to would help organizing the work.
In our team we usually develop 1 or 2 persons together.
Then the code is reviewed by around 2-5 persons in individually or in pairs
Then it is tested by 1-2 persons initially, finally tested by the whole team.
Currently our system allows us to assign a single person at a given time. That limits our ability to follow who is working on what without looking through the log for the issue. The benifits of beeing able to assign multiple persons would be good for us.
What happens if John is assigned a task and cannot finish it, and it is moved to Jane's list because John was a slacker?
Are you OK with losing history of who it was originally assigned to, and the hours that were spent / billed on it?
In an e-Learning scenario, it makes sense to have an issue assigned to multiple users.
Here is what I want to do:
I have a storyboard which I want to assign to 3 people at the same time - the animators, the recording artists and the graphic designers. Once these people finish their tasks, they will pass it on to a common reviewer, who will review and close the issue.
Graphically it would look something like this:
Storyboard
/ | \
graphics animator recording
\ | /
reviewer
|
done
The three job roles depend only on one storyboard. The compilation of the three have to go to a reviewer. I'm racking my brains to get this working on redmine. Haven't found a solution yet.
Got this answer from an Atlassian partner https://www.isostech.com/solutions/
and then later from Atlassian
Objective:
Want to set who does the works for each step on an issue
Summary:
Use a plugin to copy values from custom fields into the assignee field whenever the issue transitions to a new step.
How:
1. Install the Suite Utilities plug-in:
This plug-in adds a bunch of new functionalities to workflows.
You will use the plug-in to copy the value of a custom field to the assignee:
Create a custom field as single user picker for each role i.e., dev, tester, reviewer to be assigned at different steps in the issue
Add these fields to the issue type's screen
Modify the post-function on the workflow transition between each step
Add a "Copy Value From Other Field" post function and set it to copy the value from the appropriate user custom field into the assignee field.
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
How do you go about organizing user stories?
What I did was this for a web application:
Made a title for a web page like 'index', then listed all the stores the user can do on this page.
I continued on for all the pages.
Is this the most effective way?
I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:
As a [role] I need [capability] so that [desired outcome].
A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:
Concern: Some Activity
Context: When doing such and such
Observation: This thing should be added to the database
Observation: The thing should get a new unique ID
Observation: The thing should be related to that thing
Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)
It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):
Concern: Finding Stores
Context: When looking for a product with the best price
Observation: The web page should display a grid of store thumbnails that contain the users search product
Observation: The stores should be sorted such that those with the lowest price appear near the top of the page
Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for
The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.
Concern: Retrieving Stores
Context: When searching for Store entities containing a specific Product
Observation: A collection of StoreResultDetail should be returned
Observation: The collection of stores may be empty
Observation: Each StoreResultDetail should contain the store name
Observation: Each StoreResultDetail should contain the price of the Product
Observation: Each StoreResultDetail should contain the URL of the store's web site
Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site
The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.
Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.
Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.
In our shop, we write up Use Cases. Examples of Use Cases:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).
From the use cases, we then begin to sketch up web pages.
You can also make Use Case diagrams:
I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.
I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.
Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.
We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.