I researched some sources on Agile methodology. Below is a structure and Agile team structure that I wanted to share with by each of you.
If you approve of the structure, terminology, and team roles described below, my suggestion will be to implement, test, and formalize this agile methodology in a pilot project. If successful, we can then document these terms, processes, planning phases, and roles on OpenMRS site wiki, and refer to it for subsequent projects. In my head, I am thinking about an “OpenMRS Implementation of Agile” that considers volunteering global resources, time zone and cultural differences.
As you review this structure and roles, please consider the following questions:
- Will this make sense for OpenMRS projects going forward?
- Do the resources that we have in place now match the roles below? Will we need to recruit different types of talent to occupy these roles (ie, scrum master, product owner)?
- Does this feel like “too much” process? Will the developers welcome this level of process and structure? Or do we run the risk of alienating precious and limited development resources that have become accustomed to working in less structured environments?
Project Structure and Terminology
Ideas are captured as user stories and structured as multiple DEFINE >> CODE >> TEST process iterations (aka, “sprints”) spanning 2 weeks with periods of REVIEW and ADJUST in between each iteration.
- Point: Defines how much a team can commit. A point usually refers to 8 hours. Each story is estimated in points.
- Capacity: Defines how much an individual can commit. Capacity is estimated in hours.
- Release planning: A rough estimate is given to a user story using relative scale as points
- Iteration planning: The story is broken down into tasks.
- Requirements: Defined as a user story with acceptance criteria and tasks to implement the story
- Daily Stand-Up: A daily status meeting among all team members and it is held roughly for 15 minutes
- Release: A major milestone that represents an internal or external delivery of working, tested version of the product/system.
Release Planning: Create a plan to deliver an increment to the product. It is done after every 2 to 3 months
Iteration Planning: Purpose is for the team to complete the set of top-ranked product backlog items. This commitment is time boxed based on the length of iteration and team velocity.
Product Backlog: A list of items to be done. Items are ranked with feature descriptions. In an ideal scenario, items should be broken down into user stories.
Team roles are categorized into Team and Technical interfaces. These include the following:
Scrum Master (1) Product Owner (1)
Developer (3-4) Tester (1)