You can search for terms in the Search bar above! ;)
The Agile Dictionary
Tasks are the results of breaking down a user story into technical work that the developement team can perform. Tasks don’t have to use the User Story format as they are written by the Team, for the Team, so they use whichever format is more appropriate by the Team. Most of the time, tasks don’t deliver a functionality or business value as such but all tasks from a user story need to be completed for a user story to be considered done. User stories define the specific feature from the user’s perspective whereas tasks detail the work that has to be performed by the development Team to complete the user story.
Technical Debt (also refered as tech debt) is one of the most important concept in software development. It refers to the results of taking shortcuts in coding or not respescting state-of-the-art coding in order to ensure the delivery of the functionality before the deadline or to reduce time-to-market. It is described as debt because the piece of code will have to be refactored later to make the implementation of new pieces of code easier in the future. Please note that technical debt can also be caused by evolution of technologies, coding methods, APIs implementation and is not always intentional. As per the Agile Principle about technical excellence, there should be no technical debt in Agile. Being realistic, there will always be some technical debt, which is fine, as long as refactoring is planned and understood by the whole Team. Most Teams even plan refactoring sprints that will only be allocated to reduce the technical debt. It is called debt, because for a single feature for which you took the easy path, it might add 10% of working time for the next 20 releases for example.
Themes are large high-level organizational goals that give general topics and directions. They will regroup several initiatives in them but initiatives can also cover several themes at once.
The "three C’s" stands for Card, Conversation and Confirmation. This is the recommended process for defining user stories.
The user story should be written on a post-it note with the following format: “As a [particular user], I want to [perform this action], so that [I can achieve this goal.]”
A conversation between all the stakeholders takes place for elaboration, value estimation and validation
Confirmation is defining the acceptance criteria for the user story so the definition of Ready is clear. The tests for validating the functionality works as it should and the definition of Done for the user story are also discussed.