Is this What You’ve Been Told a User Story in the Agile Methodology is?
What is a User Story?
Simply put, a user story is the smallest unit of work in the agile framework that serves as a software system requirement.
Here is an in depth look into User stories and Agile characteristics:
What is an Initial User Story
Initial user stories are much smaller and basically define the interaction between the end user and the system in certain usages and scenarios.
Two types of Initial User stories exist: Formal and Informal.
- Formal User Stories:
These are detailed sentences that help programmers identify the actors (team leaders, members and product owners) and their business value as a requirement
A formal approach is usually applied with the template:
e.g. As a (role) I want (something) so that (benefit).
For example: As a reporter, I want a transport allowances so that I can travel and cover stories.
- Informal User Stories: -These are usually high level stories with no specified format in the actual story card. Their simplicity with no rules makes them easily distinguishable from other Agile stories.
What is an Epic?
Looking at the bigger picture after writing your user story lies an epic. This is a much broader chunk of work with a common objective.
A product owner can write a user story that seems really simple at first and puts it under a single sprint. In real sense, it becomes impossible to finish it in time and is then carried forward as an Iteration backlog.
The big user story now an epic, needs to be split into smaller user stories to obtain a better estimate of the sprint
Both the epic and user stories are used to classify the amount of work to be done. Epics differ from each organization.
Giant tech companies have bigger epics as compared to smaller companies whose epics could probably be done within a single sprint.
It’s also important to mention features under agile methodology. Features refer to the strategy layer that user stories try to accomplish.
An epic comprises of several features within which also comprise of a couple of user stories.
What is a Theme?
As a product owner, you may choose to diversify and change to other aspects to maximize on profits. A theme a large area of focus usually assigned to different teams.
A theme may or may not include epics of related proportions. The user stories in a particular team may be totally unrelated thus spanning the organization.
In the same way epics are made of different user stories, a theme is made of different epics. It is important to also mention Initiatives.
Just like features, initiatives lay the foundation of epics driving them towards a common goal.Initiatives take much longer to complete than epics. Initiatives have structural designs that clearly define the epics and their time frames.
One major characteristic of a theme is that its overly ambitious. It mostly defines the product owners’ dreams and goals in partnership with the stakeholders. They sometimes inspire the teams to create reasonable epics in regression to the original Agile idea.
The themes are used to organize the epics for better processing.
What is a User Persona?
To fully understand what a user persona is, a background check into the world of marketing is in order. Remember a developer cannot create a program without actually knowing about the consumer base and their needs.
In software development, there is a team responsible for researching related topics on the project and give feedback to their teams. This data obtained which usually contains a list of pros, cons, goals and complications are arranged in a manner that reflects a data persona.
A user persona is that a character that is a representation of a user who will interact with the product you are passing. It may be a program, an app or another software entirely designed to target how best your product will perform in the market.
If your product is a web-based feature, it is expected that it will receive more than one user. Therefore, it is advisable to create more than one use persona to adapt with the increasing number of traffic inside your website.
As mentioned above, a user persona’s initial stages of development usually comprise of market research. These include the use of prototypes that are released to beta testers who have already subscribed into testing of the persona.
The beta testers give out their general feedback of the working of the program on interviews or focus groups where they share their opinion. Areas of improvements are shared and worked on in the tasks to come.
What is an Acceptance Criteria?
According to leadingagile, they are a group of conditions that need to be met to satisfy and accepted by a user or customer.
They are one of the most important things to get right, from the start, so you know when you have done enough testing to exit the process.
Final Words on User Stories
The incorporation of user stories into software development has made the task more human friendly as opposed to other impersonal methods. Its launching is more thrilling as it contains actual conversations of the user requirements that a client demands.
As part of the team, you may need to complete a user story diligently and fast since anyone in management including the stakeholders can write a user story and add to your collection.
If not properly handled, user stories can pile up to form company backlogs which are enemies of progress.
Before you go, lets delve into another buzz word in Agile, ATDD...
Really? Is this What ATDD in Agile Stands for? The inside scoop!
What is ATDD?
One framework that has been gradually rising is ATTD, which stands for Acceptance Test Driven Development.
What is ATDD?
ATTD is an Agile based developmental framework that involves communication between the business stakeholders, customers, developers and down to the beta testers.
At the same time, the user stories once executed are passed through several detailed acceptance tests that check on how the system will perform as per the user’s point of view.
The difference between this tool and Scrum is that the latter’s User story is scrutinized by the developer and the product owner and run against several Acceptance criteria to check on its overall functionality. In other words, the tests are done immediately the user stories are written prior to any development work.
Is it also referred to as Story Test Driven Development (STDD)?
In order to clearly define what an STDD is, it is fundamental to learn about the Test-Driven Development (TDD). This methodology involves a short development cycle that is usually repeated until it passes the required test criteria.
It can be very tiresome since the first test is usually targeted to fail and with the subsequent tests geared towards software improvements.
The Story Test Driven Development is subset of the TDD that focuses on higher level acceptance tests. So, in a way the collaborative framework is also sometimes referred to as a STDD though less commonly.
The STTD comprises of four major key components namely:
- System specifics: - Written in HTML the document briefly describes how the software is expected to function.
- Acceptance Test Fixture: - This reads the system specifics Html to ascertain that the specifications are adhered to
- Unit Test cases: - As the name suggests, these are tests specifically run as a unit to make sure the software runs as intended.
- Story test results: - With all said and done, a summary of all the acceptance tests and their results are recorded here.
What about Behaviour Driven Development (BDD), is it the same?
According to gaboesquivel, BDD is a subset of the TDD. It is totally different from the collaborative framework in that its software operates on principles like, designing and programming a unit test and ensure they fail before finally implementing and verifying the implementation of the unit.
BDD generally gives a consistent customer-based reception allowing for the inclusion of everybody involved in the process whether they are conversant with developer options or not.
What this means is that as a customer, your needs will be put first before anyone else. Another difference of the BDD is that it focusses on how the system operates whereas the framework in discussion drives at carefully meeting the acceptance tests needed for efficient software functionality.
The tool structures that support the BDD include the JBehave and RBehave developed by Dan North. In these structures, the framework specifies and executes the tests for each scenario bearing in mind the schematics of the scenario.
What are the benefits of ATDD?
The long chain of activities involved in this framework finally pay off in the following ways.
- Quick solutions to problems arising: - the world of designing and developing software is challenging and filled with setbacks. As such, it requires a tool that can instantly solve some of these problems. It accomplishes these problems by sharing the design and testing it in its early stages
- Simpler to Manage: - Unlike TDD, this framework is known to incorporate everyone into it meaning, smaller user stories will be assigned to each team to be completed during a shorter timeframe. Smaller builds are usually easier to monitor and manage especially in distribution of resources.
- Customer focused: - this design puts the needs and preferences of the customer above all else. Through prior research within the market, developers have it easier to do their work especially with the needs of the consumers in mind.
- Bridges the gap between different teams: - According to qasymphony, it improves the efficiency in the development process. It's collaborative efforts initiate communication between the developers and the stakeholders alike thereby closing the gap.
What are the common Pitfalls?
Like every other software framework, the ATDD isn’t lacking in a few cons:
- This method is geared towards the customer’s satisfaction which can be a a huge blow to the product owner especially if their interests don’t align.
- The framework is designed to operate under specific tools like Cucumber that requires mastery and constant practice. As such, this will deter the primary objective of the framework to improve on the collaborative interaction between the stakeholders and developers.
Final Words on ATDD
ATTD is becoming more popular for simple reasons like anyone being able to write and run the acceptance tests. In the ever-digital competitive world, it offers more dynamic and efficient improvements to your product throughout its automation features.
If you can use a method that will get you faster results, why not take the chance?