Please login or join to subscribe to this thread
First of all, an agile programme does not exists. What exists is a program with all the PMI or other institute guidelines you follow where you will apply agile practices, where agile practices are not IT or software, agile is not the manifesto, agile is not a method or methodology, agile is not a process or life cycle. When you have this on mind then you can search ways to make your program practices more agile and gain in agility. I am working right now in my seventh initiative to implement agile at enterprise wide. So, documentation is what your stakeholders consider valuable. For example, in our case, business case and project charter are mandatory.
I have been developing an agile assurance approach for a pilot project we are doing however the principles will apply at the program level. There are effectively two streams for a review 1) the formal assurance review which reviews the documentation and 2) ongoing observation and advice through attendance at scrum of scrums, design working groups etc.
In terms of documentation for stream 1, it is mainly held in the tools that are in use such as the Kanban board and program increment board. What is key is to be able to trace the desired outcomes from an epic level down to the individual stories which is easier said than done. Once you have that in place then you really need a simple dashboard to show the story burndown chart etc. The other documents would be the business case, the project charter/initiation document etc. As there is limited documentation (i.e. no test plans or test cases which are buried in the user stories) you must be attending the various ceremonies to ensure that the risks are being discussed and captured. The rest wil follow.
The minimum to be effective within the bounds of the chosen delivery approach.
This is an Agile mindset. If something (a document, a process, a method, etc.) does not add value one should ask why it is being done.
Agile philosophy naturally resists unnecessary documentation. I doubt you'll find any sort of "minimum" documentation requirement from a reputable agility leader. Your individual organization may have minimum requirements, but that is distinct from any Agile values or principles.
There is no single right set of documentation. If your interest is in quality assurance then I suggest you evaluate the programme in terms of product quality and stakeholder satisfaction. An agile approach to development usually puts the emphasis on empirical control and customer collaboration rather than formal documentation. You may well find that features are described as a product backlog in a project collaboration tool rather than a business requirements document.
Documentation should be tailored to the deliverable.
What is the program developing? A new software system? a Process or a set of processes?
Here are some minimum documentation requirements that I would expect .
Expectation 1:- Why the project exists? Business Case, Business Proposal . evidence of such documentation having been approved or signed off , either in manual or electronic form.
Expectation 2:- Capture risks and issues in the project and make sure you are actively resolving them. These can easily exist in your electronic Project Management tool or simple spreadsheets.
Expectation 3 :- Software or the Process must be tested to make sure it meets the client requirements:-
Documentation evidence :- System/ User/Process Requirements - User stories should exist , ideally in JIRA or other suitable software. Call it product backlog, feature backlog, epics or user stories . These should be then broken down to a level where they can be executed in iterations and can demonstrate definite business value. You do the breakdown through your iteration planning , backlog grooming etc
Test scripts - must be traced back to the user stories , again, JIRA is a good tool to do that.
Test execution - electronic or manual evidence of testing being completed
Defect remediation :- system or process defects captured and resolved, electronically or in physical documents. Can use JIRA
Expectation 4 :- Software or the Process must be built to meet the client specification:-
Documentation Evidence :- There must be a design or process specification that indicates what the system or process is trying to achieve, how it is built , how it is configured, how it meets the client's requirements. You can call it As-built, design specification , process specification , handover specification anything you want .
The design or process specification may well be in an electronic tool but the client must sign off on it's delivery
Expectation 5:- On day 1, when the system or process becomes operational, who is responsible for supporting it , delivering it, owning it?
There should be a support plan, documentation ...contact details of support teams , product owners , key stakeholders. This document can be as lean as possible or electronic but it must exist . This is evidence of Transition to Operations.
Note that you can follow agile/incremental/iterative processes to develop the above documentation but the end goal is for the Client to "Sign off" on a deliverable. Enough evidence is required that you have delivered a project or process that can be operational on day 1 and support the customer's business process effectively.
Apart from that , you can have your agile ceremonies, move your cards around , show case incrementally the product features that have been delivered in each iteration , but the final product must have the required documentation that shows the end to end feature or functionality for it's operational use.
Please login or join to reply