ResourcesPM TopicsAgile Product Management with Scrum – Key Terms

Agile Product Management with Scrum – Key Terms

Share

Agile is a development methodology which prioritizes creating a small ‘slice’ of a product and having a look to see if what was developed works before starting on the next slice of product. Agile is excellent for developing software products. Agile comes in many flavors, such as Scrum, extreme programming, Lean, Hybrid and Kanban. It’s worth looking at Agile Product Management with Scrum because Scrum is one of the most common Agile methodologies in use and Product Managers should have a basic understanding of how it works.

Agile Product Management with Scrum: Sprinting to the finish

Under scrum, development occurs in short, defined periods called sprints, which are up to two and no longer than four weeks long. The goal of each sprint is to create code in an iterative and incremental way and complete a particular piece of work. This process is repeated (iterated) while the product is progressively built (increments).

Learn the Core Skills to be A Product Manager
Get Started

For each sprint, the development team takes work from the top of the product backlog focusing on the top priority items that can be developed during the allotted time. The team breaks down the work for each sprint into tasks and then executes each task. Testing occurs while the product is being built which makes for better and cheaper code.

The goals is that at the end of each sprint product could be released to customers as soon as it is complete. Most commonly, several sprints are often bundled together and provided to customers in a larger product release.

Managing the Sprint Cycle

In the Scrum summary, the product vision drives the product backlog. In turn, that drives a series of events and meetings that guide the developers during the sprint. Scrum specifies these milestones and what should happen at each of these events.

  • Sprint planning meeting: Happens at the start of a sprint. The Product Owner and the team first decide on a sprint goal. During the meeting, the Product Owner describes each user story, and the team then asks questions and plans the group’s work for the sprint. Don’t confuse sprint planning with the Agile product Management planning activity. Sprint planning focuses on the work required to complete the user stories the team committed to for the sprint. Agile Product Management is a strategic activity that provides long-term direction and spans an extended time period.
  • Sprint goal: A brief one or two sentence description describing what the Agile team is planning on accomplishing during the sprint.
  • Daily scrum: The daily synchronization meeting that takes place within the team. The team includes all the engineers. Product Owners and Scrum Masters are optional attendees. Each person stands and answers the following three questions: What did I do yesterday toward the sprint goal? What will I do today toward the sprint goal? What’s getting in the way of me doing my work to achieve the sprint goal?
  • Sprint review: A meeting at the end of a sprint where the Product Owner reviews the sprint goal with key stakeholders and has the engineering team demonstrate the completed product increment.
  • Sprint retrospective: A separate meeting from the sprint review. It can include anyone outside the development team. Typically Product Owners join this meeting. During the meetings, the team reviews lessons learned and improvements that can be made. Ideally, the team commits to making at least one change in the way that they work.

Agile Product Management with Scrum: Telling (user) stories

In Agile, you communicate the requirements through simple user stories to the developers. The user stories convey to the developer what the customer need is and what the user is trying to accomplish. Once the developer has discussed the user story with the Product Manager or Product Owner and fully understands the meaning of the user story, the developer then builds the feature.

The format of a user story is as follows:

As a [persona], I want to be able to [customer need] so that I can [benefit of requirement].

Here is a sample user story:

When is a User Story Done

One question always arises: how do my developers know when they are ‘done?’ That the user story is completed. This is where acceptance criteria come in. Many acceptance criteria are attached to each user story. In fact, historically, they were written on the back of the user story index card.

Quality folks then refer to the acceptance criteria. If the criteria are met, then the user story must be done.
Beware: defining ‘done’ is a key task for each development team. Expect that it will take a while to agree to what this simple 4 letter word means.

Not Everything is a User Story

When you have product boundaries such as: What operating system(s) should it operate under, or what temperature range should it operate within? These are better written as constraints. Simply write down the limits of what the product needs to do without reference to a customer and move on.

Agile Product Management with Scrum: The Product Backlog

Agile calls for Product Owners to provide prioritize user stories in the product backlog. The product backlog is an ordered list of user stories or larger requirements called features or epics, depending on their size. The work that has more customer value should be developed sooner. This means that the Product Owner creates more detail about the requirement so that it’s ready for the development team to get to work on. The work that will be done later on is less detailed – often a LOT less detailed. As these features and epics come to the top of your backlog, you break them down into user stories that are small enough chunks of code that your development team can work on.

The beauty of a product backlog is that one person is in charge: the Product Owner (or Product Manager in the role of Product Owner). That is an absolute within scrum. This person decides what the development team works on next.

Agile development using Scrum is an interesting balance which lets developer take responsibility and gives many opportunities for clarification and checks along the way.