Do you have a good technical overview?

Last updated by Chloe Lin [SSW] 3 months ago.See history

When running a project, having someone with a high level view of the project is extremely valuable. That person is much more likely to notice broader problems and be able to act to correct them.

It is highly effective to have this person attend Sprint Reviews and Planning. Attending Daily Scrums is also valuable but not essential; even attending occasionally has value. They could potentially also act as Scrum Master, but in many organizations they do not.

This person's objectives should include the following:

  1. Provide feedback to the Product Owner on what’s in the backlog

    • Are items sensibly sized? Will they fit into a Sprint comfortably? Should they be broken down further?
    • Are there risky items in the backlog that could do with a spike to research the risks?
    • Do the items address the goals of the project? (you'd be surprised how often the answer is no to this one)
  2. Provide feedback to the Product Owner on prioritization

    • Often a Product Owner will feel everything is most important; get them to list things in order
    • Review prioritization just before Sprint Planning
    • Try and provide tips on how to think about prioritization (asking questions like "Is A more important than B", "If yes, we should move A above B in the backlog")
  3. Provide feedback to the Scrum Master on how things are running

    • Often the Scrum Master will miss things due to being bogged down
    • Remind the Scrum Master their role is to facilitate and assist in eliminating blockers
  4. Give big picture feedback, highlighting the requirements that often get missed, encouraging the Product Owner to decide which items are most important in their context. The most common of these are:

    • Performance
    • Cost
    • Scale
    • Reliability
    • Availability
    • Disaster Recovery
  5. Provide a sounding board for technical questions
  6. Provide a backup for the Scrum Master if they take leave or any other break
  7. Identify problems. Quite often the distant observer can see impending disaster way before everyone who is stuck in the details
  8. Learn from seeing other teams in action.

    • What works well in the team being observed that might help in another project?
    • Was the response to a problem really effective?
    • What value did I bring?
We open source. Powered by GitHub