Long Term Value of Completed User Stories in Agile
In Agile, the user stories are mostly used in two different ways:
- As a unit of work by developers and testers, and
- As a description of features and functionalities to be (or have been) implemented.
In most organizations, the second point (i.e., the documentation part) is extremely underrated.
This is because, even if Agile is about "Individuals and interactions over processes and tools" and "Working software over comprehensive documentation" (as per the Agile Manifesto), in practice the team changes frequently as a result of resignations, reallocations or expansions.
When I once joined an Agile project midway (to replace another team member), I was given a list of around two thousand user stories on my first day so that I could quickly figure out what has been going on in the project so far.
And I am sure, many of you can relate yourselves with this experience of mine.
Agile doesn't mean the absence of documentation. It just means the absence of unnecessary documentation.
We, thus, sometimes miss to see the value of user stories that are already implemented in the past.
Lead Business Analyst | Probation Digital
7 年Funnily enough I've just published my own article today on the need to keep a single point of reference for all requirements. I would argue that a user story itself ceases to be useful once it's been completed, as it's only a snapshot of requirements, and the full requirements are contained, as you say, in several other user stories.
How likely is it that anyone would be able to read and understand 2,000 user stories within a few days, especially if they're new to the organisation? I'd suggest that this is probably NOT an efficient way to transfer and retain information. The question you might instead want to ask is 'What is the most EFFECTIVE way for this information to be documented?' Where 'effective' means that it will actually be clear, useful, and easy to update when changes occur in the Business Process, as well as the software.
AI and Cloud Transformation-Consultant
7 年Totally agree and at times teams make this excuse of no documentation, while Agile recommends lite documentation which is right information captured that a developer or tester can utilize during the Agile sprints.
Leader - Testing Services
7 年The pure intent of agile is getting lost in some organizations off late. Intent of Agile is to ensure you start developing requirements (logical chunks) which are crystal clear in one or more sprints while focusing on remaining requirements to make it more clear before start any work on them. Many organization do mix up RAD and agile methodologies.. Let us call it hybrid??