Scrum Practice Part 3 - Scrum Artifacts
Scrum Artifacts
They are to provide ways to represent work or value through transparency and opportunities to reflect on your process and inspect and adapt it. These artifacts are designed to make key information as transparent as possible. The Scrum Master needs to work with the Product Owner and Development Team to spread the mean of these artifacts and how that through complete transparency, the product will have reduced risk, increased value, and decisions made with the right information. Otherwise, by falsifying data given to Product Owners and stakeholder, product decisions will be made that negatively impact the user and the product itself.
**Be aware of the watermelon product/project. Its green on the outside to everyone but red on the inside black seed of risks. By being transparent, risks and issues are seen in advance and can be dealt with or worked around. Everyone wants to succeed so don’t fear to show the real picture.
Product Backlog
The Product Backlog is an ordered and prioritised list of everything that is known and is what the team will pull from for each Sprint. These items are known as Product Backlog Items (PBI).
When starting a Product Backlog, get all the known stories into the backlog. From that point, the Product Owner can rank them based on the value it can provide the users/customers. With this Prioritised list, discussion with the development team can begin moving down the backlog, understanding what is required for each piece of functionality.
It is important to understand that this list will never be completed. The product will continue to evolve and change as new requests for functionality or improvements are raised.
The higher and more valued Product Backlog Items should be more detailed and in greater clarity than those towards the bottom. More precise estimates are made based on this clarity. From this, the team will then be able to consider these for the next sprint, making sure not to over commit and accept more tasks than they can achieve. All these items need to be able to reach the “Done” state declared by the development team within the Sprint time box. Otherwise, they will need to be broken down.
The Development team are responsible for all estimates. Although these may be influenced by the Product Owner to provide any additional clarification needed or scope changes needed. However, the Development Team have the final say.
**Consider making use Story points for estimation if you are using Scrum for the first time. It allows the team to take away best guess on providing hours or days in estimation and still being held to it, even if scope or understanding has changed since that estimate. These are usually in the Fibonacci sequence and is designed to make you think when you are estimating the higher numbers. Is it an 8 or 13? By doing so, you are actively thinking about what levels of complexity sit behind this ticket. If a ticket was over 13, I would suggest it would need to be broken down for further understanding to improve the understanding of the ticket and how best to implement it.
Sprint Backlog
This backlog is made of the selected Product Backlog Items the team decided on for the Sprint, making the work visible for all to see. This should also have an ideal plan for how the team will deliver this increment and how it will reach this Sprints goal. At least one improvement needs to be added to each sprint to make sure the team is always moving forward in the interest of continuous improvement from actions taken in the retrospective meeting.
The sprint backlog items should emerge over the sprint, from requirements to functionality with value to the business. Day by day, the Daily Stand-ups will help forge this as there should be enough detail about each change that it can be understood during the stand-ups and understand how this change will affect the sprint goal.
Only the development team can commit to what is in the backlog and any changes during the sprint must be agreed by the development team and the Product Owner, but this backlog belongs only to the development team.
**As information becomes available, you may need to change what items are in the sprint, something might be more valuable with new information or a needed fix must be implemented. Consider looking at work not started, as there will be less impact of dropping and changing to a new task. Finish work that has already been started as that still will have value and pick up the new ticket when a slot becomes available. However, if this is consciously happening, the Product Owner and Scrum Master need to investigate and understand why changes are happening so frequently even though a Sprint has begun and being overridden. On the flip side, if the team run out of work, pull from the top of the backlog!
**Operate a One in One out rule, any needed change should be weighed up, if I can wait for next sprint, it needs to. Otherwise, the Product Owner will need to explain the impact to the person requesting the change, so they understand the value being delayed.
**Monitoring sprint progress is useful and should be used by the scrum team for continuous improvement and learning how to adapt their process. It is NOT a stakeholder tool to understand how much they are delivering. Each Sprint is different and story point estimates will flux. Allow the team time to adjust and understand their estimate. Stakeholders should only be interested in the potentially releasable software in the demos and what tasks are being selected for the Sprint, not the estimates the team has given.
Use tools such as Burn down, Burn Up, Cumulative flow diagrams and Average Age charts.
Increment
When referring to an Increment, this the Product Backlog Items completed in the Sprint as well as any previous increments. At the end of each sprint, the new increment is considered Done and in a usable condition that meets the team’s definition of done. This Increment is a celebrated as the step forward to the product's vision and is up to the product owner whether it is released to live.
**It is okay if the team was only able to release a handful of items. This is about the team understanding not just how they work together but what their sustainable pace is and how to improve it. The team may need to break down items into finer detail or require assistance from teams that were not considered.
Also, as mentioned, release often and if you can, why not release when an item reaches the team's Definition of Done? The Product Owner may consider giving value sooner to get an understanding of how users will react to each change. However, this does rely on the appetite for change. A release every 2 weeks may be more than enough for some customers.
Definition of Done
The Scrum Team needs to have a unified and understood Definition of Done. Done can mean different things to different people and can lead to product defects and Product Backlog Items being reworked. Having a clear Definition of Done for Product Backlog Items or Increments will lead to a better understanding of the product and increased transparency.
As the Scrum Team matures, these definitions will change and more likely strive for higher quality. This may require the team to look back and find that work previously considers done needs to be re-evaluated. For example, a higher unit test pass rate is required, or new security testing has been applied.
**When starting a new Scrum Team, work out what the current definition of done is. It is likely that if the team is set up correctly, different skill areas are working closer together, meaning different requirements. Work out the Software Delivery Life Cycle for what a single Product Backlog Item will need to go through to be a potentially shippable product. Work with this definition and when requirements or failure stops the team, make notes and improve the definition of done. Make this definition is easy to find if it is not on a poster on the wall.
Sprints
The Sprint is simply a timebox between each iteration. Within this, items of done, usable, potentially shippable functionality are built by the team ready for release. This can be between 1 week and 4 weeks although it is recommended to sprint for 2 weeks. This gives the team enough time to go through the steps and build. Also, a 2-week timebox keeps the Scrum Events from becoming a burden if too short or having long periods of time between retrospectives and feedback loops if sprinting for months at a time. However, use what works for your team, if they prefer longer sprints due to the complexity of the items of work, experiment and see what happens.
Use sprint goals to focus the team around a certain outcome. Make sure it is something achievable within the sprint cadence. This goal should be linked to user value and provide them with functionality or requests that they would actively see value in.
** When it comes to the Events, consider doing the Planning, Review, and Retrospective on the same day. This will allow one day of solid focus, leaving the others in the cadence free. By starting with the review, you can get instant feedback for stakeholders and celebrate successes. Then by moving into the retrospective, the team can reflect on not only how the sprint was received but what went well and consider how to improve for the next sprint. Then take those actions into sprint planning to be integrated with the tasks from the backlog.
**In addition, consider avoiding starting sprint at the beginning or end of a week, as people are preparing or come back from the weekend and motivation levels can be low.
