“P” as in Project. The Project covers the complete production process for the Agile team. There may be activities before the project starts, like the decisions taken to start the project and possible the overall scope settings. The Agile team is only active while the project runs.

“I” as in iteration; a project is divided into several serialized, time boxed iterations. Each is assigned a limited amount of user stories that need to finish. If the user stories are not implemented within the time boxed iteration it is considered a failure that the team must learn from so it will not be repeated. One way to handle the failure is to avoid taking on so many story points for the following iterations. Another way could be to increase the team speed.

“U” as in User stories. These are small texts that explain single functional requirements, what business value they provide and for whom. They should always follow the template “as a <kind of user> I want to <functional requirement> so that <business value>”. Example: As a team member I want to see a list of all tasks assigned to me so that I know what to do at all times.

This symbol is for a team member. A team member is anyone involved in the project and a team member can sign up for user story tasks and miscellaneous tasks. A team member is involved in estimating the size of user stories in story points. One important principle of agile estimating is to estimate size and initially avoid estimating time. The time it will take to finish a user story is derived from the speed of the team. And the speed of the team can be dependant of many things, like experience, talent and team size. The team itself decides how many story points they can sign up for in each iteration.

“T” as in task. The tasks come in two flavors; user story tasks and miscellaneous tasks. The user story tasks are all the practical things that need to be done in the produced application to actually implement the user story. The miscellaneous tasks are all the other practical things that need to be done. They can involve things that the product owner does not consider to add business value, so he or she is reluctant to provide user stories for them. And the miscellaneous tasks also describe the bug reports left over from previous iterations that need to be fixed.

The tasks are estimated in ideal hours and the team only earns user story points for user story tasks and only when all tasks for a user story are completed. They earn nothing for miscellaneous task. The idea is that a high quality producing team will get less miscellaneous task, and hence the team will produce more user story points per iteration, in other words, the team will have a higher speed. High quality shows as high speed. Low quality will force the team to a lower speed. It is easy to see that quality pays off for all parties involved.

“R” as in release. Not every iteration ends with a release but all iterations should leave production capable, bug free software products. At some intervals the product is delivered to the users in a release.

“A” as in attention. Besides releases there might be other import dates to keep track of. These might involve inter project synchronizations to signal to one project and their team important events in other projects or in their users domain.