Scrum guide suggests 3 scrum artefacts.
- Product Backlog
- Sprint Backlog
- Product Increment
During my practice I have seen and employed a number of other ‘facts’, how are they useful?
Should they be used in the practise of scrum? Let’s go through them and you can decide for yourself.
IT’S ALL ABOUT ‘TRANSPARENCY’
Firstly let’s talk about what are Artefacts and why are they important in Scrum and Kanban. Artefacts are important as they help make the work of the team visible, to each other and stakeholders. Artefacts should be a low-overhead output of other activities such as meetings, work done or decision making, they should not be deliberately produced articles.
Having Artefacts allow anyone to inspect the status and see/understand where the progress is and what has happened. As such over the last 10 years there has been increasing use of other artefacts to expand and support needs of various types of business need.
CHARTS
Although Burndown Charts are mentioned in the updated Scrum Guide, they do not specifically mention it is for a Sprint or Release. Many teams (or should I say management teams) i have worked with require updates to see where the team is in comparison to 1. the week/sprint and 2. against the whole ‘one level up’ release.
Burn Down, Burn Up
I won’t waste your time by describing this is, but it is meant to show the amount of work completed plotted out against time.
Other variants include ‘burn up’ chart or a burn down against hour work time estimate. These variants can work for teams that require tracking focused on hours spend on a project (eg. customer paying team by the hour) or where time is a critical factor and can not move.
The Burn down chart can also be scaled up to ‘release’ level, where rather than hourly or daily progress, the unit of time measurement is against sprints, past. By plotting it as a trend line you could estimate roughly when the release will end up.
While not a must for all teams, your business may require you to produce these. Do they help with transparency – yes they do.
MAPS
Product Story Map or Feature map can be used by the Product Owner to plan features and version releases. Many teams find it useful to know where the product is going, and having a map of future features gives the scrum team (especially the development team) direction to plan and work towards.
Having broken the features down into smaller work items also allow the team to plan the order of execution that needs to be done. Cross-team deliverable can also be planned to ensure things are done just-in-time.
Having a plan that makes the future work transparent that helps in planning more immediate sprints – something like this is extremely useful to teams and businesses that work in dynamic marketplace.
NOTES
Agile encourages face to face collaboration – sometimes this is mis-interpreted as ‘just talk, and no need to write down anything’. What I have seen many teams do is use electronic tools to quickly and easily capture meeting notes, decision notes and conversation outcomes.
For example, that decision that was made on path A and not path B in the kitchen over the water cooler, while critical to the team and product – it isn’t captured anywhere. The Scrum process does NOT require decisions to be captured and recorded – it is assumed the Development Team can self-manage this. However in many industries and businesses where accountability is critical, such as work on a piece of financial software, business logic decisions needs to be made and reasoning recorded for future reference.
Sometimes relying on the Development team to self-manage isn’t going to be enough decisions that was made during future audits. So capturing meeting and conversation outcomes can be important. In which case i suggest notes be made as part of those team’s Artefacts.
IN CONCLUSION
Which artefacts are needed for your team comes down to the environment the team operate within. Determine what is needed and add it to your team’s practice if it helps.
