The highest priority for any software company should be to satisfy customers right on time and continuous delivery of valuable software. And this way, a very good definition of Agile is given by Dr. Alistair Cock burn “Deliver Value to Customer quicker, minimize bureaucracy”. Why are many software organizations battling with this? There are many reasons: development testing, organization culture, hierarchical organization, requirements.
Let’s focus on software requirements and see what is the issue with software requirements?
- Requirements do change regularly. Different surveys show that over 35% of all requirements change during a typical software project.
- Very often the customer doesn’t know what he/she exactly needs. Regardless of whether a customer knows what is required, he/she may struggle to express or define requirements. Even regardless of whether the customer characterizes the requirements well, we may have totally misunderstood the customer and implement something completely wrong.
Thus, the issue with software requirements is a communication issue. What would be advisable for us to do? User Story is an Agile requirement technique which can help with this challenge. User Story is a great technique for representing requirements; though, many teams have issues in using User Stories.
Here is a great video about User Stories – Agile Practices:
What Are Agile User Stories?
- A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s point of view.
- The purpose of a user story is to articulate how a piece of work will deliver a specific value back to the client. Note that “customers” don’t have to be external end users in the traditional sense, they can be interior customers or team members within your organization who rely upon your team.
- User stories are a few sentences in a basic language that outline the ideal result. They don’t really go into detail. Requirements are included later when agreed upon by the team.
- Stories fit perfectly into agile frameworks like Scrum and Kanban. In the scrum, user teams are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their work process. It’s this work on user stories that assistance scrum teams improve at estimation and sprint planning, leading to progressively accurate forecasting and more agility. Because of stories, Kanban teams figure out how to oversee work-in-progress (WIP) and can additionally refine their work processes.
- User stories are likewise the building blocks of bigger agile frameworks like epics and initiatives. Epics are large work items broken down into a lot of stories, and various epics include an initiative. These bigger structures guarantee that the everyday work of the development team contributes to the organizational objectives built with epics and initiatives.
Challenges with User Story are:
- User Stories are too huge (Epics) – These stories can’t be completed, and they are “traveling” from sprint to sprint. It is very demotivating for the team, impede flow, velocity; it slows down team learning. Epic should be part of spilled User Stories before taken into a sprint. When we have small User Stories that are surely understood, valuable and actionable, then they are ready to complete.
- User Story is hazy to the development team or PO – Typically, there no clear acknowledgment criteria and development team which is trying to understand “scope of the story, how this story fits with the general objective of the product, or how to specify the tests”. Developers need to understand certain things about User Story to implement it well. Unclear User Story causes lots of waste during a sprint, and again stories are traveling from sprint to sprint.
- Lack of discussion about User Story – User Stories are the placeholder for further discussion: they’re complemented with a conversation that happens between Product Manager/Product Owner and development team. Many organizations apply User Stories without additional conversation: to account for missing conversation, Product Owner attempts to write detail-rich and exact User Stories, which isn’t what User Stories are for. Two choices exist:
- Make sure that an effective discussion takes place.
- Alternatively, utilize different description techniques for requirements, for example, Use cases
- Wrong purpose – User Stories describe end-user requirements, they aren’t intended to capture technical requirements. If development teams heavily depend on technical requirements, this may show that development teams are component teams. An effective way to reduce the requirement for technical requirements is to reorganize the teams by forming feature teams.
User stories describe why and behind the everyday work of development team members, regularly expressed as persona + need + purpose. Understanding their role as the source of truth for what your team is delivering, yet why, is key to a smooth process.
Start by evaluating the next, or most pressing, large project. Break it down into smaller User stories, and work with the development team for refinement. When your stories are out in the wild where the entire team can see them, you’re ready to get the chance to work.
For more blogs: https://blog.aleph-technologies.com/
As a company comprised of individuals who have seen the vast number of improvements the Agile mindset can bring, It has become our resolute mission to bring Agile practices to every workplace the world over.