Search

Are You Writing The Best User Stories In Agile?

WHAT IS A USER STORY?A user story is a part of an Agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.They generally follow a simple approach for a user story:As a < type of user >, I want < a goal > so that < a reason >.Another approach includes:As a <user type>, I want <a goal> because <why>.Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them prominently in any major Agile process.What does a user story mean? Let us try to understand with an example.Imagine you are using an app on your phone. Now, you like the app, but you would love to have an additional feature in this app. How would you describe your wish to the developer of the app? You will say something like-"I want to have X functionality so that I am able to get Y benefit."While creating a user story, you write in the exact same way, the only additional information which you need to provide is about the type of user you are.The advantages of user stories can be written at different levels in details. We can write a user story to cover a huge amount of functionalities. These large user stories are generally called ‘epics’. Let us clarify this with a few more examples-“As a user, I can view the license terms before purchasing or subscribing so that I know what I’m getting.”“As an app user, I can read FAQs, so I can get quick answers.”“As a website admin, I want all the offers to get unpublished on the website after 7 days of publishing so that the expired offers are not still listed if I forget to delete them.”In all these examples, it is clear who want the features, what they want, and what benefits they would get with the additional functionality.WHO WRITES THE USER STORIES?Business people are responsible for writing the user stories in a customer-specific language. We have to do this because we want user requirements to be clean and clear to both the development team and the business. The role of a development team is to satisfy the end-user acceptance criteria of the storyboard. In Scrum process, the product owner is responsible to represent the business as well as to finish the activity.WHEN TO WRITE USER STORIES?In an Agile project, User stories are generally written in the end. Usually, writing a user story workshop is held close to the beginning of the project in Agile. Everyone should participate in writing or adding the user stories to the product backlog at any time. If your team members are predicted to deliver the stories, then roughly we have to maintain 3 sprints of user stories in the backlog. The additional aspects of efforts and features are a superset of user stories. In these cases, the product owner team interacts with the development team to split user stories into enough levels.WHY ARE USER STORIES USED IN SOFTWARE DEVELOPMENT?User stories are used because they provide many benefits in software development. Here are some of them.User stories help in delivering value to the customer.User stories talk about the immediate customer needs. Because of this, the features implemented and delivered to the end user is of  the highest value.User stories enable a project to be quickly adjustable.Since user stories help in adding small features one by one, it becomes easier for the developing team to steer towards new direction if it is required.User stories increase the collaboration of end user.Since user stories are short, the people involved in the project need more explanation from the end user to clearly understand the story. This increases user collaboration.User stories are followed by Acceptance Criteria. Acceptance Criteria clarifies the end user that in which situations the story will be fulfilled. They are a list of requirements. They are written in "Given, When, Then" format.Let us see an example for a clearer understanding of user stories. Suppose, there is a story for a website user which goes like this-"As a logged out user,I want to be able to sign in to the website,So that I can see my previous transactions."Now the acceptance criteria for this story can go something like thisScenario: The registered user signs in with a valid username and password“Given I am logged out of the websiteand I am on the Sign-In page.When I fill in the “Username” and “Password” fields with my valid credentialsand I click the Sign-In buttonThen I get signed in to the website”Acceptance criteria help in creating a clear understanding between the developers and the clients about when and how the features will work. The client understands what to expect from the project. And hence, the chances of miscommunication between the parties get reduced.
Rated 3.5/5 based on 4 customer reviews
Are You Writing The Best User Stories In Agile? 200
Are You Writing The Best User Stories In Agile?

WHAT IS A USER STORY?

A user story is a part of an Agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.

They generally follow a simple approach for a user story:
As a < type of user >, I want < a goal > so that < a reason >.
Another approach includes:
As a <user type>, I want <a goal> because <why>.

Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them prominently in any major Agile process.


What does a user story mean? Let us try to understand with an example.

Imagine you are using an app on your phone. Now, you like the app, but you would love to have an additional feature in this app. How would you describe your wish to the developer of the app? You will say something like-

"I want to have X functionality so that I am able to get Y benefit."

While creating a user story, you write in the exact same way, the only additional information which you need to provide is about the type of user you are.

The advantages of user stories can be written at different levels in details. We can write a user story to cover a huge amount of functionalities. These large user stories are generally called ‘epics’. Let us clarify this with a few more examples-

“As a user, I can view the license terms before purchasing or subscribing so that I know what I’m getting.”

“As an app user, I can read FAQs, so I can get quick answers.”

“As a website admin, I want all the offers to get unpublished on the website after 7 days of publishing so that the expired offers are not still listed if I forget to delete them.”

In all these examples, it is clear who want the features, what they want, and what benefits they would get with the additional functionality.

WHO WRITES THE USER STORIES?
Business people are responsible for writing the user stories in a customer-specific language. We have to do this because we want user requirements to be clean and clear to both the development team and the business. The role of a development team is to satisfy the end-user acceptance criteria of the storyboard. In Scrum process, the product owner is responsible to represent the business as well as to finish the activity.

WHEN TO WRITE USER STORIES?
In an Agile project, User stories are generally written in the end. Usually, writing a user story workshop is held close to the beginning of the project in Agile. Everyone should participate in writing or adding the user stories to the product backlog at any time. If your team members are predicted to deliver the stories, then roughly we have to maintain 3 sprints of user stories in the backlog. The additional aspects of efforts and features are a superset of user stories. In these cases, the product owner team interacts with the development team to split user stories into enough levels.

WHY ARE USER STORIES USED IN SOFTWARE DEVELOPMENT?
User stories are used because they provide many benefits in software development. Here are some of them.

  • User stories help in delivering value to the customer.

  • User stories talk about the immediate customer needs. Because of this, the features implemented and delivered to the end user is of  the highest value.

  • User stories enable a project to be quickly adjustable.
  • Since user stories help in adding small features one by one, it becomes easier for the developing team to steer towards new direction if it is required.
  • User stories increase the collaboration of end user.

Since user stories are short, the people involved in the project need more explanation from the end user to clearly understand the story. This increases user collaboration.

User stories are followed by Acceptance Criteria. Acceptance Criteria clarifies the end user that in which situations the story will be fulfilled. They are a list of requirements. They are written in "Given, When, Then" format.
Let us see an example for a clearer understanding of user stories. Suppose, there is a story for a website user which goes like this-

"As a logged out user,
I want to be able to sign in to the website,
So that I can see my previous transactions."

Now the acceptance criteria for this story can go something like this

Scenario: The registered user signs in with a valid username and password
“Given I am logged out of the website
and I am on the Sign-In page.
When I fill in the “Username” and “Password” fields with my valid credentials
and I click the Sign-In button
Then I get signed in to the website”

Acceptance criteria help in creating a clear understanding between the developers and the clients about when and how the features will work. The client understands what to expect from the project. And hence, the chances of miscommunication between the parties get reduced.

KnowledgeHut

KnowledgeHut Editor

Author

KnowledgeHut is a fast growing Management Consulting and Training firm that is a source of Intelligent Information support for businesses and professionals across the globe.


Website : http://www.knowledgehut.com/

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

How to Launch Your 1st SAFe Agile Release Train

So, you are excited to organize and launch your 1st SAFe Agile Release Train. Understanding the importance, structure, and deployment of ART (SAFe Agile Release Train) is the central of SAFe Agile implementation to scale & successfully implement the complex projects, deliver maximum business values and complete the project on time well under the budget. Just like a train carries its passengers to deliver at set destinations within pre-estimated time at defined cost, ART also helps you carry out the projects successfully; however, before starting the journey with an efficient ART, you must know the principles that govern Agile Release Train.    10 Steps to Launching your First SAFe Agile Release Trainhttps://t.co/dNWUfCwMBd pic.twitter.com/rT8FDhqcoj — Yves Mulkers (@YvesMulkers) 27 January 2018 5 Governing Principles for SAFe Agile Release Train:  ART is the self-organised team of Agile Teams. It is composed of Agile teams engaged in development, security, DevOps, Enterprise Architecture etc. ART plans. It commits & executes the processes following a specific timeframe often called - PI (Program Increment). ART must follow a value delivery model for periodic planning and timely release.  ART must follow a common iteration length within the PI.  ART must know the clearly-defined objectives & benchmarks. ART must follow the culture of continuous system integration. The works completed by different teams must be integrated at each sprint to keep the developments in releasable state. ART must respect customer previews, internal reviews, and system level QA.    Roadmap to Launch SAFe Agile Release Train:  1.Train the SAFe Program Consultants (SPCs): Train your SPCs properly, the change agents responsible for transformation and connecting the Scaled Agile Framework (SAFe) to your organization. SPCs teach all the stakeholders & leaders to drive the ART to its destination.  2.Train the Lean Agile Leaders: Lean Agile leaders are expected to understand and implement the principles of SAFe Agile framework. Lean Agile Leaders are also responsible to lead & facilitate SAFe adoption for improved outcomes. And for smooth transition, you need to train the Lean Agile Leaders up to the best standards.   3.Identify Value Streams and ART:  SAFe Agile Release Train is a procedural system; therefore, you should make all the responsibilities of solution defining, building, validation, and deployment etc clear.  4.Organize ART and Agile Teams:  The roadmap to organize the ART and Agile teams contains different millstones including:   Well-defined ‘product’ with features/components Leadership support Collaboration Minimized dependencies Integration Well-managed DevOps activities 5.Define and Fill All The Roles Of ART Members:   The critical roles of ART members must be well defined to help the Release Train Engineer, System Architect, Product Managers, Scrum Masters, Product Owners perform the best at par with customer’s expectations.     6.Prepare the Program Backlog:   The practice of using launch date as the forcing function makes it more urgent to determine the scope and vision of PI. The scope of ‘what is built’ or PI is defined by ‘Program Backlog’ informing about the upcoming features, architectural work, and NFRs. The gained vision about the future behaviour of system helps you create short stories for Agile teams.        7.Train the Teams Train the teams properly to deliver the maximum values at each sprint. It is the key part of ART readiness to ensure the on-the-time best quality ‘product’ delivery. 8.Conduct PI Planning  PI planning is a face-to-face meeting event; it empowers the Agile Release Train to align all the SAFe Agile teams for the shared mission & vision.  9.Set the Program Calendar & Launch Date  Now you have ART definition. The next task is scheduling your 1st PI Planning event focused on the forcing functions and ‘date-specific’ launch with PI calendar. The PI calendar shows the scheduled activities including PI planning, System demos, ART sync, Inspect & Adapt (I&A) workshop etc.  10.Execute Innovation and Planning Iteration:  Now, you are almost at the destination. Innovation and planning iteration is conducted to absorb the variances in estimates, allot time for innovation, refine backlog and to plan ‘Inspect & Adapt’ workshop.  Conclusion: Launching SAFe Agile Release Train (ART) for the first time can be a challenging and complex task; therefore, before going ahead, you should acquire the expertise by joining short-term SAFe 4 Release Train Engineer certification training designed to guide you through for efficient ART launch. .   
Rated 4.5/5 based on 7 customer reviews
How to Launch Your 1st SAFe Agile Release Train

So, you are excited to organize and launch your 1st SAFe Agile Release... Read More

When Do We ‘Scrum’ Down?

The following is a statement I hear very often from managers of Software Development companies. “We are way better in Software Engineering than we used to be, from the time we started to follow Scrum.  Our engineering practices were not very strong when we were doing traditional SDLC based development, but now we are way better”. How valid or acceptable is that statement? Can Software Engineering become better with Scrum? Or is it actually directly tied with the Project Management Approach? Rather than challenging this statement or keeping you waiting further, let me shed some light as to when an organization can be effective by adopting Scrum. When analyzing the effectiveness of a Project Management Approach it is primarily important to understand why Scrum came to being and to understand what sort of issues it is actually meant to solve. A primary objective or construct of Scrum is to make “things” more visible and measurable. What are these things? This involves every work product, deliverable, activity, process step, output and every other element in a project. So, Scrum is expected to make, Plans more visible, visual and trackable Requirements more visible Designs more visible Code and documentation more visible and measurable Test cases and scenarios more visible Project progress more measurable Blockers or impediments more visible and so on. Scrum is all about progress. Collaboration and communication to solve issues and take things forward is an important principle in Scrum. It encourages decisions to be made by the right people as soon as possible and to keep everyone involved, interested and informed. We already know this… Wait!! Isn’t this what we always hear about Scrum? Isn’t this what we already know about Scrum? Well Yes!! But does it paint a complete picture of Scrum?Unfortunately Not!! My belief is that it is equally essential to understand what Scrum is NOT!! Scrum is a project management methodology but does not define engineering practices. What exactly are engineering practices? A company adopts standards, methods, practices, frameworks etc. from knowledge around requirements, design, development, testing, infrastructure management, etc. and defines its own engineering framework. It may involve best practices, technologies, tools, techniques and everything else to successfully design, develop and deploy a solution. What happens if your Scrum team lacks engineering practices? I am an ardent sports fan and thought of pulling in some examples from different sports and sports personnel. A team adopting to follow scrum without having a proper platform in terms of engineering practices in place is like, McLaren trying to win a Formula One race by asking Michael Schumacher to drive a TATA NANO Asking Sachin Tendulkar to bat on a badly curated pitch and score a triple hundred No matter how proficient a race-car driver Michael Schumacher is or how genius a batsman Sachin Tendulkar is they would not be able to succeed in their specific sport. Simply because a TATA NANO is not fit for a fast paced race and since a dangerous and underprepared pitch is not suitable for a cricket match. In short, it is not possible to drive, if engine is not up to the expectations in terms of engine capacity and it is not possible to bat if the pitch or the cricket gear is not according to modern standards. Scrum is NOT about the engine, it is all about driving the vehicle… The engine of a software development team is the engineering practices followed. These are things such as how coding is done, reviews are done, documentation is done, testing is done, resources are planned, infrastructure is managed, and so on as mentioned previously as well. It is important to know that none of the above is specified by Scrum. Scrum provides the guidance on how to navigate the road. It will tell you how to take a bend, when to slow down, when to speed up, when to look back and see what to change or improve, and so on. So as we see, it’s like trying to compare apples with oranges. Instead we need to figure out what we can make combining apples and oranges. XP contributing to the confusion around!! Agile comes in different flavours. More than 12 flavours of Agile exist and contribute in shaping and moulding each other. Many get confused by trying to understand Scrum by comparing it with XP (Extreme Programming). XP, in addition to its project management principles and practices has gone beyond and defined some good engineering practices. If I list some of these, they are constructs such as unit testing, continuous integration, pair programming etc. One can even argue that XP is actually more than a agile based project management methodology. So in Conclusion!! Following Scrum makes a lot of sense for a company with properly defined and diligently followed engineering practices. But when no proper engineering practices exist, it is quite easy to try hide your incapabilities under the comforting umbrella called ‘Agile’. Unless you address your problems related to software engineering processes in your company, adopting Scrum will most probably end up giving negative results. Do not use Scrum as a means to fix your engineering process. It is impossible and just a futile task!! Think about getting your engineering processes and practices sorted out first before adopting a suitable project management methodology. You may first explore standards such as CMMI, ISO, etc. for the same. This can be discussed in a separate article, but hope this will be a starting point to you all.
Rated 4.0/5 based on 20 customer reviews
When Do We ‘Scrum’ Down?

The following is a statement I hear very often from managers of Softwa... Read More

Do You Have Your Agile GPS Handy?

Once I was driving late at night after attending a wedding of my office colleague and had a team mate to drop who lived in the meandering by lanes of Najafgarh. It was Delhi winter season (around 1am) and people who are familiar know the dense & foggy conditions during this time. After taking circuitous lanes, we finally reached his place. Alas, on my back I forgot the route because of both an unfamiliar suburb and misty conditions. Fortunately, I had a GPS in my car which provided me the directions to reach my residence. Now replicate this situation on an organization which is going through an agile transformation journey and want to know how is the as-isagile adoption doing, things which are going well and the ones which need improvement and what will it take to reach an end state of being a high performing hyper productive agileorganization? Is there a GPS solution to assess agile maturity of teams? Yes, indeed. Organiq Agile Maturity (OAM) model is an industry proven, lean and light-weight agile health indicator which can measure agility at an organization, portfolio or a team level using a 5-star dimension-characteristics model embedded in a 4E approach. It helps assess the current state of agile implementation, key summary findings, SWOT, transformation roadmap along with next steps to reach the future state. OAM is facilitated by experienced agile coaches by interviewing cross functional agile teams with a survey questionnaire, facilitating enterprise retrospectives, observations from agile artifacts and attending ceremonies with the teams. Data is fed into a mathematical model which helps arrive at the maturity, crystallize strengths, areas of opportunity and a transformation roadmap for the organization. Typically, such an agile maturity assessment takes anywhere between 2-4 weeks depending on the scope, geography and team size under consideration. As enterprises are becoming more agile they want to know where they are standing with respect to the industry and their competition. As they say, “You cannot improve what you cannot measure”. OAM helps you measure and improve your agile journey. Do you have your Agile GPS handy?
Rated 4.0/5 based on 20 customer reviews
Do You Have Your Agile GPS Handy?

Once I was driving late at night after attending a wedding of my offic... Read More