Search

How to Write A Well-Formed User Story

Bill Wake has given us the mnemonic INVEST which help us in writing a well-formed User Story.   Working with User Stories may be easy, but writing effective User Stories can be hard.Top challenges in Writing User Stories:Getting teams engaged.Adding too much or too little detailSplitting stories.            Reminder!!!!!!!!!!!!!!!Story writing workshop is important to understand the User Story in details and who are the users of that particular functionality and what the users do to use the product.Conduct a Story writing workshop Quarterly.Three tips for a successful story writing session are:Set the single objective for the meeting.      Objective should be MVP (Minimum Viable Product.) and engage the team in various discussions on top user Stories with the Product Owner.Have the right participants,       Scrum master, Product Owner and other stakeholders, Development team (Agile coach) (optional) may be User Roles.Ask the Product Owner about the top requirement/features to be delivered.In MVP, Brainstorm the requirements in detail which will help in a more innovative solution.Visualize the relationship between stories.User Story Mapping technique:Document each step in the process. Writing the sequence of steps needed to complete the user  story will make it clearer which may have been overlooked and easier to estimate. The chances of missing any functionality can be minimized.We can read the below functionality is Login and enter credentials, you may also click on “forgot password” and then submit.Another advantage of using mapping is that we can get the prioritized list of user stories as mentioned in the below diagram by lanes.SPIDR has come to our rescue. Beautiful concept given by Mike Cohn.How to Split a User Story: Biggest challenge…Spikes: -The user story is large and difficult to split when there is a spike activity involved in it. Spike doesn’t lead to any working functionality but it just for the knowledge enhancement for the team for example-Investigation of new technologies and investigating different tools etc.Paths: - The user story may be large because of the different paths associated with it. See the flowchart below to understand the example: In an e-commerce website, after selecting the items the payment method cart, the payment method can be visa card, mastercard or PayPal.So, it is recommended to split the user story based on the number of paths taken.It can be easily logically split into small stories as:As a <user>I want to pay using credit card orAs a <user>I want to pay using PayPalHere, there is no need to split using visa card or mastercard, as both come under the category of credit cards.Interfaces: - Split a story across multiple interfaces (mobile OS or browser) or data interfaces.Example: As a <user >I want to display in Android device.As a <user > I want to display in IOS device.As a <user > I want to display in web browser.So, it can be split into 3 different logical user stories.Same is the case with the browser also. Split by different browsers example: Chrome, IE, Mozilla etc, because working in all browsers will take time and the efforts would be large.There are a few scenarios in which there are complex interfaces. A perfect example will be a sign-up form (with the details) but blank UI. It means the functionality is fully working with buttons and links but no color and proper UI/UX image. The UI can be built in subsequent sprints with a different user story. So, separating the UI work with functionality is also a good way to split the user story.There is a similar case when the user story says- As a <user> import data from a file and note says (Must support: CSV, Excel and XML) Split each supported file format with different user story as-As a <user> I want to import data from a CSV.As a <user> I want to import data from an Excel.As a <user> I want to import data from an XMLData: - Develop an initial story with a subset of data.Example: Suppose I need to buy a car.As a car buyer I want to know what is the best car in the market.To come up with this decision, we need to investigate many things example consider mileage, cost, big, small, comfort, features etc. as a separate user story.As a car buyer I want to buy a car with minimum cost.As a car buyer I want to buy a car with good mileage.So, a functionality is developed incrementally with different data inputs to buy a car.Rules: - Relax business rules or technology standards in an initial version of a story.Sometimes a user story is considered as large because of the different business rules or business standards.Example: I want to buy something online for my kid’s birthday party, at least 15 items.But website shows there is a limitation of 2 items per buyer.Relaxing a rule is sometimes followed by a user story which is a great way to split.For example, in a project, we develop some functionality (sort the employees with their skill set). This will be a database query and may take quite a few seconds depending on the load. So, there is a performance issue which is very important to consider. Better to split this as a separate user story.Add the right amount of detail to the user story. Not too much detail not very less…The right balance is required… But how to find out if the details are in correct proportion or not?The answer is “Retrospective”. Ask each team member if the detail that was given was enough to complete the user story in one iteration.JUST ENOUGH AND JUST IN TIMEThe reason is that if the information provided by the BA is not sufficient to complete the user story in one iteration, then there will a delay in the project delivery and customer will not be happy. Similarly, if the detail is too much then a lot of work in upfront needs to be done and the project delivery will be on time and with the exact functionality which was decided before the start of the sprint more like a waterfall modelA very important aspect while defining the user stories is about user roles. Avoid writing user stories from the perspective of a single user, identify different user roles who will interact with the software. Write stories for a single user.Create constraint cards or write tests to ensure the constraints are not violated.Keep the user interface out of the stories for as long as possible.Let us see some examples of user stories which look fine but can be written in a much effective way.1) As a Product Owner, I want to display my ratings on my webpage.Issue/Drawbacks- It is not only about “you”. Focus on End users and stakeholders.Correct: As a trainer, I want to display my ratings on my web page so that the visitor can choose wisely.2) Design Brochure LayoutDrawbacks: Not independent, No business value.Correct: As a restaurant owner, I want to design Brochure Layout so that the visitor gets order from it. “Identification of who what and Why are the key factors”So, the user story suggested format/template is:As a <>, I want <> so that <Business value>.Few more examples:StoryDescriptionThe user can run the system on windows xp and LinuxGood user story, but still suggested to split into three(Windows,XP and Linux)The user can undo up to 50 commandsGood user storyAll graphing and charting are done by third party library.Not a good  user story as user will not care how graphing and charting are done.The system will use log4j to log all the messagesNot a good  user story and log4j should not be written as logging mechanism.The user can export data to XMLGood user storyA user can quickly master the systemNeither quickly and master should be defined.Needs to be changed
How to Write A Well-Formed User Story
Shilpi
Rated 4.0/5 based on 3 customer reviews
Shilpi

Shilpi Jain

Blog Author

Shilpi is an experienced Scrum Master have 9+ years of experience in IT industry. She worked in companies like GE Healthcare and Nokia Siemens and currently working as a freelancer where she has contributed in many Technical Articles on Scrum/Agile, Project Management Tools (Atlassian, Jira and Rally), Project Management, Scrum Agile Certifications Questions and Answers (Test Paper Writing). She carries certifications like Certified Scrum Master, Fundamentals of Scum, Certified Six Sigma Black Belt (CSSBB). She always shares her personal experiences in her Articles. She is a passionate writer and blogger about the Scrum and Agile Methodology.

Posts by Shilpi Jain

How to Write A Well-Formed User Story

Bill Wake has given us the mnemonic INVEST which help us in writing a well-formed User Story.   Working with User Stories may be easy, but writing effective User Stories can be hard.Top challenges in Writing User Stories:Getting teams engaged.Adding too much or too little detailSplitting stories.            Reminder!!!!!!!!!!!!!!!Story writing workshop is important to understand the User Story in details and who are the users of that particular functionality and what the users do to use the product.Conduct a Story writing workshop Quarterly.Three tips for a successful story writing session are:Set the single objective for the meeting.      Objective should be MVP (Minimum Viable Product.) and engage the team in various discussions on top user Stories with the Product Owner.Have the right participants,       Scrum master, Product Owner and other stakeholders, Development team (Agile coach) (optional) may be User Roles.Ask the Product Owner about the top requirement/features to be delivered.In MVP, Brainstorm the requirements in detail which will help in a more innovative solution.Visualize the relationship between stories.User Story Mapping technique:Document each step in the process. Writing the sequence of steps needed to complete the user  story will make it clearer which may have been overlooked and easier to estimate. The chances of missing any functionality can be minimized.We can read the below functionality is Login and enter credentials, you may also click on “forgot password” and then submit.Another advantage of using mapping is that we can get the prioritized list of user stories as mentioned in the below diagram by lanes.SPIDR has come to our rescue. Beautiful concept given by Mike Cohn.How to Split a User Story: Biggest challenge…Spikes: -The user story is large and difficult to split when there is a spike activity involved in it. Spike doesn’t lead to any working functionality but it just for the knowledge enhancement for the team for example-Investigation of new technologies and investigating different tools etc.Paths: - The user story may be large because of the different paths associated with it. See the flowchart below to understand the example: In an e-commerce website, after selecting the items the payment method cart, the payment method can be visa card, mastercard or PayPal.So, it is recommended to split the user story based on the number of paths taken.It can be easily logically split into small stories as:As a I want to pay using credit card orAs a I want to pay using PayPalHere, there is no need to split using visa card or mastercard, as both come under the category of credit cards.Interfaces: - Split a story across multiple interfaces (mobile OS or browser) or data interfaces.Example: As a I want to display in Android device.As a I want to display in IOS device.As a I want to display in web browser.So, it can be split into 3 different logical user stories.Same is the case with the browser also. Split by different browsers example: Chrome, IE, Mozilla etc, because working in all browsers will take time and the efforts would be large.There are a few scenarios in which there are complex interfaces. A perfect example will be a sign-up form (with the details) but blank UI. It means the functionality is fully working with buttons and links but no color and proper UI/UX image. The UI can be built in subsequent sprints with a different user story. So, separating the UI work with functionality is also a good way to split the user story.There is a similar case when the user story says- As a import data from a file and note says (Must support: CSV, Excel and XML) Split each supported file format with different user story as-As a I want to import data from a CSV.As a I want to import data from an Excel.As a I want to import data from an XMLData: - Develop an initial story with a subset of data.Example: Suppose I need to buy a car.As a car buyer I want to know what is the best car in the market.To come up with this decision, we need to investigate many things example consider mileage, cost, big, small, comfort, features etc. as a separate user story.As a car buyer I want to buy a car with minimum cost.As a car buyer I want to buy a car with good mileage.So, a functionality is developed incrementally with different data inputs to buy a car.Rules: - Relax business rules or technology standards in an initial version of a story.Sometimes a user story is considered as large because of the different business rules or business standards.Example: I want to buy something online for my kid’s birthday party, at least 15 items.But website shows there is a limitation of 2 items per buyer.Relaxing a rule is sometimes followed by a user story which is a great way to split.For example, in a project, we develop some functionality (sort the employees with their skill set). This will be a database query and may take quite a few seconds depending on the load. So, there is a performance issue which is very important to consider. Better to split this as a separate user story.Add the right amount of detail to the user story. Not too much detail not very less…The right balance is required… But how to find out if the details are in correct proportion or not?The answer is “Retrospective”. Ask each team member if the detail that was given was enough to complete the user story in one iteration.JUST ENOUGH AND JUST IN TIMEThe reason is that if the information provided by the BA is not sufficient to complete the user story in one iteration, then there will a delay in the project delivery and customer will not be happy. Similarly, if the detail is too much then a lot of work in upfront needs to be done and the project delivery will be on time and with the exact functionality which was decided before the start of the sprint more like a waterfall modelA very important aspect while defining the user stories is about user roles. Avoid writing user stories from the perspective of a single user, identify different user roles who will interact with the software. Write stories for a single user.Create constraint cards or write tests to ensure the constraints are not violated.Keep the user interface out of the stories for as long as possible.Let us see some examples of user stories which look fine but can be written in a much effective way.1) As a Product Owner, I want to display my ratings on my webpage.Issue/Drawbacks- It is not only about “you”. Focus on End users and stakeholders.Correct: As a trainer, I want to display my ratings on my web page so that the visitor can choose wisely.2) Design Brochure LayoutDrawbacks: Not independent, No business value.Correct: As a restaurant owner, I want to design Brochure Layout so that the visitor gets order from it. “Identification of who what and Why are the key factors”So, the user story suggested format/template is:As a , I want so that .Few more examples:StoryDescriptionThe user can run the system on windows xp and LinuxGood user story, but still suggested to split into three(Windows,XP and Linux)The user can undo up to 50 commandsGood user storyAll graphing and charting are done by third party library.Not a good  user story as user will not care how graphing and charting are done.The system will use log4j to log all the messagesNot a good  user story and log4j should not be written as logging mechanism.The user can export data to XMLGood user storyA user can quickly master the systemNeither quickly and master should be defined.Needs to be changed
Rated 4.0/5 based on 3 customer reviews
4510
How to Write A Well-Formed User Story

Bill Wake has given us the mnemonic INVEST which h... Read More

Does Scrum Apply To All Types Of Projects?

Scrum, undoubtedly, is one of the potentially viable approaches to managing software development projects. Scrum is just a development methodology which delineates the processes and practices that help in managing software development activities.However, before adopting any methodology one should ask these questions -Is the use of Scrum being forced upon you to fit into the project?Has the research been done to predict its success rate?Have you analyzed the risks associated with this adoption?What types of projects fall into the purview of Scrum framework?I worked in the IT industry for 9+ years on a wide variety of projects where the success rate of Scrum was very high. Hence, I got the impression that it works for all types of projects. Here is my experience with one of the projects that threw away all my misconceptions about Scrum and changed my opinion.My team worked on a huge, multi-dimensional project, that included distributed teams.Multiple versions of the product were already out in the market and customer satisfaction was running high. Then we decided to switch to Scrum for this particular project. As the software product was already out in the market, customer issues and complaints piled up that were assigned a priority level in order to be resolved.The team working on the newer version was also required to support the older versions as a part of the contract with the customer.  Therefore, the same team is working on new versions of the product including enhancements and new features while also addressing the customer issues and bug fixes for the older version of the software.Now, since the product owner had already groomed the backlog for the software release, whenever any new issue from the earlier versions was raised by the customer, we took them on priority. This leads to these issues being constantly added in the midst of the sprint to the backlog and the whole team started working on the issue, leaving their current work behind.As a result of these mid-Sprint changes-All of a sudden, team had to shift their focus.No planning was done for this issue while grooming.Unplanned work being added to the backlogDelay in creating and delivering current project deliverables.Then comes the conundrum -Are we really using Scrum the right way? Is our project really getting any benefit by using Scrum?The answer is probably NOT. But the management still wouldn’t agree and will continue to force the use of Scrum for this project.Now, let us discuss the below scenarios.1) Sometimes there were too many issues from the earlier versions but the other times too few issues (but of high priority) were thereIn these cases, we need to immediately switch our focus to a high-priority issue and provide a possible solution to the customer as early as possible. The current sprint needs to be cancelled and pending tasks need to be transferred to the next sprint.2) Sometimes no issues at all.Continue the sprint.3) Sometimes issues need to be addressed but the current project is also in a critical stage.An example is the build failure of the current project and where testers weren’t able to continue the testing. This becomes a critical condition for any project which needs to be addressed and planned for.Because of this critical situation, management switched its stance and agreed to abandon Scrum for this project as it stalled both the projects and instead used the waterfall model.Few suggestions to avoid this scenario -Make two separate teams - one for handling the issues of earlier versions and one for the current project sprintsSlowly and steadily we should stop giving the support to the earlier versions (End of life) and this should be clearly communicated to the customer in advance so that they can also prepare themselves. It should be coded in the contract at the time of signing. However, this is not always possible due to complex nature of projects that run big manufacturing and production plants which may adversely affect their productivity/throughput.The above two solutions can be addressed in the following ways:Plan and allocate budget to provide support to the earlier versions of the product instead of hiring the new team. In case of no issues, the team can continue to work on the current project.For such projects, Scrum and Kanban both methodologies should be used.Conclusion:In my opinion, before adopting any methodology we should always deep dive into it and understand its success rate in different scenarios of the project. We should not impose any methodology on any project by giving justification that it is already used by other projects.Also, start off with small (maybe internal) projects having few sprints and few team members just to predict the success rate of the methodologies and frameworks.“It’s better to fail first than at the end”.So, for the projects where there is high unpredictability (don’t know when new tasks will come), chances are there that Scrum may not work; so it is better to use Kanban in those situations.Inappropriate application of Scrum can lead to its doom – Scrum is not a prescriptive method, but a suggestive approach to software development. So, the way it is implemented makes all the difference.
Rated 4.5/5 based on 5 customer reviews
Does Scrum Apply To All Types Of Projects?

Scrum, undoubtedly, is one of the potentially viab... Read More