Tag Archive: product owner


Agile Product Ownership in a Nutshell

This short animated whiteboard presentation nails the critical points and subtleties of being an agile product owner.  It includes a nice discussion around the conflict and synergy between “Building the Right Thing”, “Building the Thing Right”, and “Building It Fast”.  If you have any questions about how to excel as a product owner or how your product owner can add value for your team, this video answers it all in less than 15 minutes.

;

Scrum in one page

Here is the Scrum agile method summarized in one page:

How the Scrum method works:

  • There is one Product Owner (e.g. a business analyst) for each project and he/she creates a prioritized wish list called a Product Backlog.

    • The backlog is an ordered list where the most urgent item is #1, the second most urgent item is #2, etc.

    • The Product Owner is the only person who can change the priority of items in the Product Backlog.

  • During Sprint Planning, the team (i.e. developers, testers, and dbas) pulls a small chunk from the top of that wish list (i.e. the most urgent items) and decides how to implement those pieces.

    • This chunk of the Product Backlog is called the Sprint Backlog.

  • The team has a fixed amount of time, a Sprint, to complete its work (usually two to four weeks) and meets each day to assess its progress (daily scrum).

  • During the sprint, the Scrum Master keeps the team focused on its goal and removes impediments to productivity.

  • During the sprint, the Product Owner can change priorities in the Product Backlog, but cannot change priorities to the Sprint Backlog.

    • The Product Owner is the go-to person for the team to get clarification on functionality or usability.

  • At the end of each sprint, the work should be code-complete, tested, and ready to deploy to prod.

    • Items not completed are put back into the Product Backlog, to be finished in a later sprint.

    • Therefore the sprint deadline is never extended to finish items or for any other reason.

  • The sprint ends with a Sprint Review and Retrospective

    • Sprint Review is where the sprint’s progress is demoed and discussed with the product owner (and ideally, the customer).

    • Sprint Retrospective is where the team discusses ways to improve productivity and eliminate pain.

      • Rule #1 of the retrospective is that no person or part of the organization is allowed to be blamed for problems. Processes allow people or parts of the organization to be inefficient, therefore the discussion focuses on how processes can be changed to improve the situation or remove impediments.

      • The best improvements are taken from the retrospective and implemented in the next sprint.

  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

  • The cycle repeats until enough items in the product backlog have been completed for a prod release or a deadline arrives. However, work can be stopped at anytime and finished items can be deployed to prod in a short amount of time in a fully workable and tested state.

(This is a summary of the Scrum Framework in 30 Seconds – yes, a summary of a summary)

© 2017 Robert Corvus