We don't need to tell anyone who is used to working with SAP that getting the terminology right is often a daunting task. Agile project management brings with it a number of new terms that are critical to understand in order to be able to comprehend any of the detailed discussions on how agile can help you implement SAP solutions in a better way. These terms are by no means universal, but at BestXperts we do try to use the terminology that is most common in the agile circles, regardless if we are talking about SAP implementation projects or building a web application.
This is the agile version of a project manager, with a much cooler name and none of the silly traditional project management rubbish (WBS structures, detailed Gantt charts, etc.)
The person who is ultimately responsible for prioritization and acceptance of delivered features on a given project.
Each release is associated with some type of go-live where a number of features are moved to production. For example, a "big bang" SAP implementation project could have just a single large release. A more phased approach could lead to many releases within a single SAP implementation project - SAP ERP Finance and Human Resources in one release and Logistics modules taking place in a separate release shortly after.
These are sometimes called Epic Stories or Epics. Features represent large sets of functionality, for example - sales order processing, warehouse management picking, month-end close, etc. At BestXperts we often try to build our feature around SAP's list of best practice scenarios.
Each user story describes a particular business requirement and is assigned to a single feature. In many ways a user story is the next level down in terms of detail after a feature. We try to generally follow the traditional user story format of "As a a WHO I need WHAT so that I can WHY" replacing the WHO, WHAT and WHY accordingly. For example, "As a Sales Administrator I need to capture the authorization code when I am creating a sales order so that I can ensure that we are authorized to send an invoice". User stories are business-centric, not technology-centric. They do not capture HOW something will be accomplished technically (that comes later).
We generally try to avoid tracking detailed tasks, but sometimes we need to breakdown a single user story into multiple tasks and assign those to different people. For example this can by handy for tracking ABAP development tasks. Each task belongs to one and only one user story. Generally speaking, it is the lowest level entity that we track.
A sprint is typically a pre-determined period of time (2 weeks, 4 weeks, 6 weeks, etc.) within which a set of identified user stories needs to completed. At BestXperts we have found sprints to be too rigid for SAP implementation projects and prefer to use the Kanban variation of agile project management methodology, which doesn't make use of sprints.
A visual board where columns represent a state that a user story can be in, for example - planned, blueprinting, realization, testing, done. Stories are arranged on the Kanban board and moved from one column to another as progress is being made. Many teams build physical Kanban boards by using tape and post-it notes. We at BestXperts have historically used digital Kanban boards. Target Process is a great option, if you are looking to migrate to a digital Kanban board.
A retrospective is a focused session where your team looks back at how the current agile approach is working and which areas can be improved. Many agile teams conduct retrospectives at set intervals of time (every 8 weeks or at the end of every sprint).