De-jargoning Agile - PM Article a small attempt
- Premalatha Balan
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between selforganizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. (Ref: Wikipedia).
How much of that can a newbie to Agile understand? Most, I presume, with just a few words that need further explaining. Agile gets quite interesting as one dips a toe or tries to deep dive. There are many stock phrases, but one has to get used to the idea of jargon as you go into technology development.
The technological world is filled with jargon and if you want to delve deeper, you will definitely have to get used to some phrases too. In terms of jargon related to Agile, swim lanes, pipelines, roadmaps — are just the tip of the iceberg.
Agile transition is struggling in many places. The first reaction I see in companies and people who are going through such transition is their dislike of jargon or their feeling of intimidation in reaction to the flurry of jargon. This only turns into a flood submerging them as they try more. No wonder they want to swim away from it!
Hence, a humble attempt:
As an Agile practitioner, I want to translate some Agile jargon into simple and clear words so that anyone who wants to know what this is all about can get some idea.
User Story - The sentence above is my 'User Story' for the title of this article. It is an epic*. It is the user story of the Product Backlog* I am going to build. The Customer* in this case is someone, who has or has not been exposed to Agile before, but would like to learn what these words mean. This would enable him/her to understand the benefits of it so that he/she can use it in their area of work (ooh there is a 'user story' evolving right there!).
Could we say, that the 'user story' is a story that defines the purpose of why this is required by the customer? - To de-jargon, what is the Acceptance Criteria* for this user story?
1. One, or few, words explaining the meaning of the jargon
2. Simple words used.
3. No additional jargon thrown in.
So, could we say that - A 'User Story' is a story that defines the purpose of why this is needed?.... de-jargons the jargon "user story"?
The user story is usually written in a certain format:
As a xxx
I want, yyy
So that, zzz
Writing it in the above format helps to get the purpose clearly defined.
As a xxx - is the one who is doing it.
I want yyy - is what he/she wants, - or is the problem he/she is trying to solve,
So that zzz - identifies the purpose of why this is needed
Does the above de-jargon 'User Story'? There is one problem in the user story that I have written to explain the title. It is written in the Solution Domain* not in the Problem Domain*. Did you notice that? There is a reason why I have written so. Try to find out by your own
List of jargon used above and possible simple meanings:
Epic* - a huge thing to do, with many unknowns and uncertainties that are not clear yet.
Product Backlog* - a to-do list to achieve the objective of the product (title is the product in my above user story).
Acceptance Criteria* - a list that unambiguously defines what are the things that need to be achieved in order to consider the job is done*.
Done* - the goal is achieved and no more work is needed. No further revisiting required
Solution Domain* -an issue is explained in the way it is being to be solved
Problem Domain* - an issue is explained in terms of the problem that needs to be solved
Customer* - the beneficiary of the solution that is being developed