User stories and agile methodology in development
Before we jump into the topic of what exactly user stories are, let’s say a few words about the when we should encounter the term!
User stories and agility can be found mostly in the field of IT field, but agility and agile methodology are not explicitly or necessarily limited to this field. What’s more, the agile methodology didn’t stand out for anything that is IT specific.
What is agile, what is agile methodology? How does agility appear in the IT sector and in web development, and application development?
The essence of agility is to be flexible in handling changes and emerging requests for problems. The four values of the agile manifesto, which means agility itself:
- Preference for individuals and personal communication over methodologies and tools:
(It doesn`t mean that we forget the usual methods and tools, but that a personal discussion and contact helps a lot more than sending a message or email, or much more forward-looking when you have questions.) - Preference for a working product (software) over a comprehensive description and documentation:
During the classic development process, complex long documents had to be created before testing, however, running software is the preferred one, and the documents could be done later. - Preference is given to cooperation with the customer / client over contractual negotiation:
Of course, a contract is also needed, but it can be negotiated even during development, as opposed to references to a continuous contract. You have to work with the customer! - It prefers the ability to change over the slavish pursuit of plans:
Instead of forcing a non-functioning plan to follow at any cost, it is more beneficial if it adapts to possible changes. Nothing, so neither the developments will be 100% in line with the initial ideas, usually the final product is even better.
Let`s say a few sentences about the user stories already mentioned in our previous posts and the acceptance criteria / acceptance criteria!
A common feature of agile methodologies is that the well-defined tasks are given to the actors (we think this should be the case everywhere) who solve them , those tasks` best-known name is "User Story".
Defining the expected behaviour of a feature is the most important part of the development, as questions and expectations may arise in connection with any small feature, which need to be clarified, and these questions / expectations should be asked in the earliest status possible in case of cost and time efficiency.
The best possible way to do this is a joint planning with the customer and the developers, which not only gives a clear picture of the business need itself or the customer`s ideas, but even in the initial phase it can be revealed whether something can be given / expected. or even replaced by a cheaper and / or better solution. (It`s more cost-effective and easier for developers not to rewrite an existing feature, but to develop it well from the start.)
What should be described in the acceptance criteria during the development preparation phase?
Well, based on the above, we also cover the expected functionality seen from the user`s point of view, as well as the possible hidden / non-hidden but not clear functions. Using a simple example, if you want to put a registration in the form of a user story, it could look like this:
As a user coming to the site, I want to be able to store my user data in an interface that I can use to log in later.
Acceptance criterias:
- During the registration flow the user is able to register their account on the "/registration" url of the site, they have to fill "email address"; "password"; and "confirm password" fields and after they checking "I accept the contents of the GUA" checkbox will be saved in the database.
- The user can only log in to the interface of the page after clicking on the confirmation link sent to the specified email address.
- The text of the checkbox and its reference both can be changed in the admin interface/backoffice.
- During registration, the user will also be subscribed to the newsletter system, which will also be show "accept by tick". Feel free to add the small additions to the acceptance criterias that are important to us!
Apparently there is no technical information / decision in the description, we try to leave it to the professionals to make them, we only clarify the needs in the clearest possible form so that all the necessary information for the plan/design is available to them!
Lastly, a well-designed feature can be further extended to other features in the future, so don’t be reluctant to share your plans with developers, believe they won’t steal our “fantastic” and “market unique” ideas.
Author: Istvan Dombi
I work on IT development area since 2010, I had luck ever since to work on from simple corporate websites to e-commerce platforms and various API integrations (payment gateways and other third-party APIs) to complex international web applications. My main stack is backend development, within that PHP and GO languages.