Scrum is one of the most popular Agile frameworks. We have discussed elements of Scrum in some of our previous posts. In this post, we review the overall Scrum framework and how it works.

Scrum would approach project management by requiring the Product Owner to specifically outline the vision and tentative release dates for a product/ project. She is also required to draft an initial set of requirements and sort them by priority in what is called a project or product backlog. The team then gets together with the Product Owner and estimates the requirements broadly. The Product Owner can then re prioritize the requirements, if needed. Once this is done, the Agile iterative and incremental process starts. The team takes a guess at how much work it can do in a particular sprint. They pick the requirements that can fit into the first sprint, re-estimate them better and to a finer detail. This might involve asking Product Owner more questions. This is done usually during the first half of the Sprint Planning Meeting. Once the team and the Product Owner come to an agreement on what requirements are to be taken up during the first sprint, the team moves to second phase of Sprint Planning Meeting and breaks the requirements into actual tasks constituting what is the initial sprint backlog. The sprint clock has now started.  These tasks are updated through out the sprint in what is called a sprint backlog. The team meets daily, to synchronize the efforts. At the end of the sprint, the team demonstrates potentially shippable code to the Product Owner and other stakeholders in Sprint Review. The team incorporates feedback and Product Owner reprioritizes the backlog. Both decide the date for next Sprint Planning Meeting and start another sprint afterwards. Between the next Sprint Planning Meeting and Sprint Review, the team undertakes a Sprint Retrospective. The team identifies process improvements during this meeting and over a period of time, sprint after sprint, takes an iterative and incremental approach to process improvement as well. A Scrum Master, is designated with the task of ensuring that Scrum is followed in spirit and letter.

This was more of a How-to of Scrum. We would discuss a Lean view of Scrum in our next post.

Popularity: 13%

Posted on April 1st, 2008 by admin
Filed under: Introduction, Practices | 1 Comment »

The Product Owner is the wringable neck in Scrum. They are responsible for:

• Write down the requirements for the project
• Prioritize the requirements
• Release schedule for the project
• Be available during the sprint and sprint planning meeting to:
  • Explain business context of each requirement to the team
  • Explain acceptance test criteria for each requirement to the team
• Provide feedback on working features developed by the team during sprint review

As seen above, the Product Owner controls the release schedule and requirements or “what is to built” and “when it is to be built“. She leaves “how it is to be built” generally to the team. The team can provide the Product Owner feedback on these two dimensions, but it is primarily Product Owners call on these two issues.  It is important to note that although Scrum and Agile are collaborative processes, the Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders. This is one of the pivots for “business alignment” in an Agile Process. Although, the term Product Owner is used mostly in Scrum, it is increasingly being used to reference a “Marketing or Business role” in most Agile teams.

Another important aspect with most software projects is that there may be more than one stakeholder for the project. However, in this case as well, there would be only one product owner. As discussed before, the product owner can discuss with as many people as she likes and use any medium to arrive at her list of requirements and their priority, but only one product owner would ideally prioritize the requirements as well as set acceptance criteria for each requirement. This is to ensure that “what is being built” and “when it is being built” are very clear through out the project. In case there are more than one stakeholders/ customers, the product owner can work with them during the sprint writing the requirements or getting market feedback on requirements for prioritization.

A product owner is sometimes also aided by testers [who help frame acceptance tests for requirements] and business analysts [who help frame requirements, business context]. That is why most business analysts and testers are ideal people to graduate to a product owner role. An ideal product owner would combine business analyst, testers and marketing profile. In addition, here are some things the product owner should not do:

• Pressurize the team into committing to more requirements than they are comfortable with for a sprint. If she feels, the team is under committing, she can bring this to Scrum Master or Agile Coache’s attention and discuss during Sprint Review. The idea is to discuss the issue, rather than use subversive and non-collaborative tactics.
• Make changes during the sprint. This is done to keep the team focused. In case the product owner feels the need to make changes to the sprint regularly, the team might want to consider whether their sprint length is too long that does not allow product owner opportunity to inspect and adapt at her end.
• Be unavailable during the sprint. It is important that the product owner or proxies are available to answer any team questions as they arise. The idea is to keep the keep on track and empowered to keep moving without having to wait for information.

A product owner hence is the window through which the Agile team interacts and integrates market dynamics in a software project.

Popularity: 8%

Posted on February 29th, 2008 by admin
Filed under: Introduction, Leadership | 2 Comments »