Agile ERP Implementations – Artefacts
This post is an extension of the overview – read this first: Agile ERP Implementations
Artefacts and project document flows vary by the size of a project so I would use this as a generic guide only.
The Scrum methodology states the following Artefacts are needed:
- Product Backlog – list of desired product features
- Sprint Backlog – list of product features to be developed in a specific Sprint
- Increment – a working product based on all Sprints completed to date
In addition to the Scrum methodology an ERP implementation may need additional Artefacts:
- Issue Backlog – list of issues or changes
Other working documents that may or may not be needed depending on the size of the project are:
- Setup documents – module configurations with specific setup sequences
- Interface documents – complex interface scenarios
- Data migration documents – complex data migration scenarios
- Test documents – test scripts to verify if a feature has been fulfilled
- User Procedures – end-user procedures and user guides
- Training documents – end-user training documents
- Cut-over document – complex go-live scenarios needing coordination of interfaces, data migration and people
Some working documents like the setup documents should be regarded as part of the Increment and final documentation where others is only relevant during the ERP project.
Some documents like user-guides and training documents for a feature could with some advantage be created during the Sprint developing that feature.
The working documents are normal documents for an ERP implementation so they will not be discussed further in this article.
The Scrum document workflow is as follows (disregarding working documents and project size considerations):
Keep in mind the above diagram indicates that multiple Sprints and Sprint Backlogs can exist at any one time whereas there is only one Product Backlog; Increment and Issue Backlog throughout a Scrum ERP implementation project.
Product Backlog
The Product Backlog is owned and maintained by the Product Owner throughout the whole Scrum project.
The Product Backlog in accordance to the Scrum methodology contains all features, functions, requirements, enhancements, and bug fixes. Well this would be rather impossible to manage in an ERP implementation as just the requirements may be in the hundreds and issues/bugs may run into thousands. To put all functions into the Product Backlog would not add any value as with an ERP system one would expect certain basic functions to exist like “Ability to create a journal”.
The Scrum methodology also states that the Product Backlog is dynamic and constantly changing – an approach that would be dangerous in a large scale ERP implementation. For an ERP implementation it is necessary to manage changes to requirements due to multiple stakeholders; costs; resources and dependencies. Change to the Product Backlog should be agreed in the steering committee to ensure any impacts are properly assessed.
The Product Backlog must be tailored to ERP Implementations so it becomes manageable and value added. The Product Backlog should only contain requirements specific to the business having the ERP implementation and the requirements must have an owner or a sponsor who is responsible for the desired need – ideally grouped by functional area and type of requirement like legal; business or non-functional.
Other qualifying items may be priority, cost and dependencies. Dependencies are necessary in ERP implementations as even if the Receivables module is the most important for the project you must implement the General Ledger first and before doing this you must define security and chart of accounts and so forth.
Suggested Product Backlog fields:
- Requirement – id; name and description of the feature
- Type – legal; regulatory; business or non-functional like performance and security
- Status – open or closed
- Owner – the person; stakeholder or department needing the requirement
- Functional Area – module area or discipline
- Dependency – referring id to a dependent feature
- Priority – must have, highly desirable, nice to have
- Estimate – duration
- Sprint – id of assigned sprint
Other fields may be necessary depending on the size and needs of the project.
Sprint Backlog
A Sprint Backlog is owned by the Scrum Master and is created for each Sprint.
The Sprint Backlog is populated with selected Product Backlog features and then enriched with subtasks needed as part of the development ensuring that each feature/item is measurable down to 1-2 days. This detailed breakdown ensures easy tracking and removes the need for separate planning within a Sprint.
Issue relevant for the Sprint may be added from the Issue Backlog.
Issues encountered during the Sprint should be added to the Sprint Backlog as a subtask and if not resolved during the Sprint or if outside the Sprint scope – the issue should be added to the Issue Backlog.
Suggested Sprint Backlog fields:
- Development Item – id; name and approach of feature/subtask/issue
- Type – feature; subtask or issue
- Reference – requirement id or related development item id
- Status – open; setup; developed; tested; accepted or cancelled
- Assigned – assigned Sprint team member
- Estimate – duration (if estimate is >2 days additional subtasks are needed)
For a successful Sprint – all or most of the development items should have accepted hence a Sprint item do not have a priority.
When the Sprint is complete the Product Backlog is updated from the Sprint Backlog which then cease to exist.
Increment
The Increment is owned by the Product Owner throughout the whole Scrum project.
The Increment is the accumulated working product of the latest Sprint. In an ERP implementation this is a new base-lined instance of an environment – normally called gold. When a new configuration or development has been successfully tested and accepted – it is applied to the gold environment and then backed. The new gold environment is now ready for go-live or the next Sprint.
A type typical ERP implementation Sprint could be done as follows:
The Sprint environment is the clone of the gold environment where development; changes and test are being made. As the Sprint environment contains dirty data - the base-lined changes must be re-applied to the Gold Environment. The Gold backup is needed in case something goes wrong during the base-line setup.
The environment is maintained by the infrastructure team on an on-going basis and is therefore outside the Agile ERP implementation methodology.
Issue Backlog
The Issue Backlog is owned by the Product Owner throughout the whole Scrum project but can be maintained by the Product Owner and the Scrum Master(s).
The Issue Backlog is an ERP implementation specific need due to the high number of issues; changes and bugs normally occurring in an ERP project. Many issues are also be cross-functional and could be outside the scope of the current Sprint and hence should be tracked outside the Sprint.
If the ERP implementation scope is only one or two modules then this Issue Backlog could be avoided by including the issues in the Product Backlog.
Suggested Issue Backlog fields:
- Issue Item – id; name and problem description
- Reference – related requirement id
- Status – open or closed
- Priority – critical, important, cosmetic
- Estimate – duration
- Approach Id – id of assigned Sprint Backlog or Product Backlog item
Any issue can be selected for a Sprint Backlog or converted into a Product Backlog item if it’s a new feature.