Agile Artifacts Standardization Process
It would be nice to shed some light onto the importance of the role of artifacts in agile software development.
What are Artifacts
Artifacts are known from the Scrum Artifacts, which desribe the specific entities that represent the Transparency aspects of Scrum, they are used in the Scrum Rituals as elements of Inspection. The Scrum Teams Adaptation of the work- or informationflow gets decided in the Scrum Retrospective.
I found the master thesis of M. Gröber from 2013 concerning the topic of listing artifacts and modelling their dependencies. From page 40 onwards artifacts are listed and then put in an UML diagram: http://www4.in.tum.de/~kuhrmann/studworks/mg-thesis.pdf
Gröber combines agile artifacts reported from different projects into one model and describes their interrelations.
Artifacts displayed here are Code, Test case, Backlog item, Requirement, Feature, Task:
I think his model structures very well where different artifacts emerge and how they are embedded in an organic system. (An organic system combines features of living systems – such as recircularity, reciprocity – with the growth of different organs that represent a specific system functionality. See related: https://en.wikipedia.org/wiki/Organic_organisation)
An agile artifacts standardization process would basically compare 1) the quantity of an artifact (e.g. Backlog Items, Sprint Throughput, ..) and 2) the transition of work items from one artifact into another (e.g. Sprint Backlog Item gets processed into code, Impediment Backlog creates new Backlog Items, ..).
Please see a more complete lists of agile artifacts evaluated for a standardization process at the end of my previous blogpost: https://blogs.sap.com/2016/12/16/estimating-the-shape-of-agile-teams/
The quantities of step 1) number of entities of an artifact can be compared at different states of a specific project, or between different projects, to evaluate the progress of the standardization process.
The project specific qualities of 2) transition of work items are direct representatives of the flow of a project. They consist of actually getting the work done (workflow) and coordination costs (information flow).
The ways people interact and collaborate in a project can be evaluated to project specific needs, but also be compared when there is a need for cross-project collaboration:
It makes sense to have similar ways of working, because the teams can collaborate easier for dependency specific effort, when following similar processes of gathering and working upon requirements.
What can we do with this view on artifacts?
It might be the case that the ticket artifacts are merely used as an end point of writing down requirements, rather then modelling the ticket artifacts in a way that the developer can transition them to code.
An AASP would come up with questions such as:
Does the way the ticket (backlog item artifact) is put up serve the meaning to create working software (code artifact)?
And might suggest a change in the use of artifacts rather then demanding the work to get done – anyhow.
Thanks for reading!