Repetitive Activities

These tasks comprise one of five core types:
 * Calendar Events
 * Quality Problems
 * Obstacles
 * New Artifacts
 * and of course, Repetitive Activities.

Tasks in this category consists of things which must be done on a regular basis.

For example, every month a report is created, or every year certain government documents need to be submitted, or every week plants in an office need to be watered. These are habits we need to establish or attributes/qualities of our work that we need to include in our Cycle Plan. The tasks in this category are most closely related to day-to-day operations and therefore teams can benefit (every day) by refine these activities and making them as efficient as possible. (See Habits and Repetitive Activities in the Team Member Training Manual.)

Time-based Repetitive Activities
These events occur periodically, such as hourly, daily, weekly, bi-weekly, per semester, per Cycle, per Progress Meeting, etc.

Examples:
 * daily sales summary report: occurs daily.
 * yearly preparation of government documents: occurs per annum.
 * OpenAgile progress meeting: occurs after every Work Period in a Cycle.

Event-based Repetitive Activities
Repetition does not just refer to a time period. For example, there may be specific activities a team will take each time they get a lead for a new client. They don't know exactly when they'll get new leads, but they know that certain activities have to be repeated for each lead.

Tasks in this category are most often represented by a list that states what the work is and how often it must be done A Repetitive Activity is often written so that it can follow this template: "every ____ we will _____." For example, we might have a Repetitive Activity that says, "every day we will check voice mail", or, "every new lead we will enter their contact information into our customer relationship management system."

These tasks may result from a Calendar Event. For example, a trade show would be classified as a Calendar Event but may generate follow up work, such as phone calls and potential client visits. As well, employees' birthday celebrations are considered Calendar Events but the actions, such as finding a venue, buying a gifts and making an invitee list, repeat with every birthday.

These tasks may also result from irregular but known/expected business activities. For example, the preparation of an invoice is required every time a product or service is delivered to a client or an accident report may be an required each time an employee experiences an injury or accident. In other words, these sorts of events aren't expected on specific dates, but their occurance requires or triggers specific action by one or all team members.

OpenAgile Beyond Software Development
Agile methods (such as Scrum) typically break tasks into small increments and do not directly involve long-term planning. This works very well for teams working in the field of software development and can be applied with relative ease to other "development" environments. However, tasks which require time and effort not related directly to the "Product Backlog" are difficult or impossible for Scrum teams to fit into their Sprint plans.

OpenAgile is different in that it makes special considerations for Calendar Events and Repetitive Activities which enable teams to use OpenAgile in environments which require long-term planning and the management of regular operations. OpenAgile's uniqueness in this regard has enabled its adoption in environments as varied as software development, mining, and post-secondary education.

Example Scenario
Imagine a small team of I.T. specialists at a police station are responsible for the development of a new intranet, the maintenance of LDAP/file/e-mail/web/database servers, and must provide customer support (help desk) for the H.R. and e-mail systems. Such a team may be able to clearly identify a Product Owner and Product Backlog related to the development of the new intranet, and may even be able to accomodate some of the system maintenance tasks into their Sprint plans; however, the bunch of chickens who are constantly pecking at the help desk would be considered disruptive to the Sprint plan and it would be difficult or impossible to wrap Scrum around this team's entire set of responsibilities.

OpenAgile, in contrast, enables this team to recognize all requests at their help desk as Repetitive Activities and, furthermore, help them to both measure (upon reflection) and estimate (in planning) their capacity to absorb those "interuptions" amongst the other four types of tasks. If the team is not able to commit to the development of required New Artifacts or cannot resolve their Obstacles due to the high volume of Repetitive Activities triggered by requests at their help desk, they'll be able to acknowledge it as a Quality Problem and thus address it accordingly.

Repetitive Activities versus Repetitive Events
Repetitive Activities in the Cycle Plan are not to be confused with repetitive events. A Repetitive Activity, as explained above, is a specific type of action that team members must perform on a regular basis: examples may be as simple as "make coffee" or as complex as "administer patients' meds". Repetitive events, however, are regular occurances of events which are often delegated or automated: examples may be as simple as "garbage pickup every Tuesday" or as complex as "nightly build". A repetitive event is something which occurs regularly and the team must be aware of it but does not need to perform its action.