Basics of Scrum … Part 3: What are the scrum artefacts and how will the Rangers use them?

  • Article

The third part of a small series as mentioned in A pre-amble to the basics of Scrum, this post is focused on the scrum artefacts and how we see them fit into the Visual Studio ALM Rangers world of projects. It continues from the post Basics of Scrum … Part 2: What are the scrum time boxes and how will we use them in our the distributed, virtual and part-time world?.

IMPORTANT POINT: It is important to emphasize that the intent of these posts are to share my understanding of Scrum, my initial thoughts on the distributed Rangers environment and the use of Scrum, and to discuss the content to be in a position to formulate a Scrum-based framework which will add benefits in our distributed, virtual and usually part-time Rangers projects that warrants the cost. Your candid feedback is therefore appreciated, either by adding a comment or sending me an email

image Basic Scrum Artefacts

Product Backlog
  • Managed by the product owner!
  • List of business requirements and priorities
  • Only the highest priority items are typically detailed, which implies that detail decreases both in terms of requirements and priority as we go down the product backlog.
Release Burndown
  • Is a graph that records the remaining product backlog estimated effort across time.
  • Is a burn down as we start with X work and should end with 0 (done).
  • Chart changes as the team (not the product owner) grooms the estimates of the backlog over time.
Sprint Backlog
  • The sprint backlog defines the tasks that are considered to be part of the sprint, turning backlog items into a complete product that meets the “done” criteria.
  • Items not completed in a sprint are not moved to the next sprint, but instead are added back to the product backlog.
Sprint Burndown
  • Similar to the release burn down, the sprint burn down “visualizes” the work completed and remaining within a sprint.
  • Is is a burn down as we start with X work and should end with 0 (done).
  • Healthy burn down chart:
    image
  • Example burn down charts that indicate problems:
    image image image

Highlighting the key roles on the Visual Studio ALM Rangers Projects Scrum Guide quick reference poster:

image

  1. .. area which highlights the product backlog   and the ownership by the product owner.
  2. … area which emphasizes the backlog grooming and also mentions the important impediments backlog.
  3. … area showing the sprint backlog and items.

The backlog and sprint backlog items are all centralized within the iterative cycle. This is intentional to highlight that the project and the sprint are based on the product backlog and the sprint backlog, both of which are owned and maintained by the team, not external stakeholders.

Team Of Soccer Players With A Soccer Ball Heads Putting Their Hands Together During A Huddle Clipart Illustration Image

Some initial thoughts on artefacts within Rangers projects

Visibility is key … so if we evolve Scrum in terms of roles and time boxing as discussed in the previous posts, we have zero leeway in terms of implementing, using and making the artefacts visible.

Key objectives are:

  • Flexibility
  • Low administrative overhead
  • Internal and external access to all stakeholders
  • Transparency
  • Accuracy

The options we currently have are:

  • Continue using and improving our Rangers Scrum Workbook, which has rudimentary planning and reporting features.
    image
  • Using Team Foundation Server and the Agile Process Template
  • Using another Scrum and/or ALM solution or tools

I have an idea which option I would prefer and which is probably the correct option to pursue for our environment … but, I would like to hear your views first.

Closing thought …

The essence of success of Scrum, in my opinion, is definitely the transparency, but more importantly the ownership, which includes selection,  estimation and grooming of the product backlog, and the iterative (learning) nature of the framework. Rather than a Swiss precision analysis and design, followed by clinical development, we are pursuing an iterative and experimental development lifecycle. If I think of my three boys, this is exactly how they tackle any “real life” challenge, be it a new video game or one of the seemingly ridiculous challenges set by their parents … and without thinking too hard or doing an in-depth study, they master video games and the other challenges much quick and better than those of use starting with the read-me-first instructions.

What is next? Well, we now have to “scrum” amongst the Rangers, determine how to adopt, inspect and adapt the Scrum framework. This is definitely not the last post, as we will be transparent with our experiences and evolution along the road of Scrum :)