84.107.249.12: /* Priority and the Level of details */

2016-02-10T15:59:38Z

Priority and the Level of details

New page

[[Category:Scrum]]
[[:Category:Scrum]]

= About Delegates =
* Current role
* Theoretical knowledge about project management?
* Practical experience with PM
* How many of you have heard about Agile/Scrum

= SCRUM =
== SCRUM Test ==
* What are three roles in SCRUM?
* What is the major difference between Scrum and traditional project management?
* What is the role of a project manager in Scrum?
* Who is more important, a Chicken or a Pig?
* List all meetings in Scrum
* List the duration of the meetings
* How do you change the duration of the sprint?
* Is it product increment?
* Who first started using agile methodologies?
* Who first used the word "SCRUM"
* What W. Royce wrote about "Waterfall" model in his article in 1970?
* How to measure progress in SCRUM?

== Scrum Process ==
[[File:Scrum Process 2.png|500px]]

= Product Owner Role =
== Product Owner ==
An extract from http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf

* The PO is responsible for '''maximizing the value of the product and the work''' of the Development Team
* The PO is '''the sole person''' responsible for managing the Product Backlog (PB)
* Product Backlog management includes:
** Clearly expressing PB items (PBI);
** Ordering the items in the PB to best achieve goals and missions;
** Ensuring the value of the work the Development Team performs;
** Ensuring that the PB is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
** Ensuring the Development Team understands items in the Product Backlog to the level needed

* The PO may do the above work, or have the Development Team do it
* However, the PO remains accountable.
* The PO is one person, not a committee
* The PO may represent the desires of a committee in the PB, but those wanting to change a backlog item’s priority must convince the PO
* The entire organization must respect his or her decisions.
* The PO’s decisions are visible in the content and ordering of the PB
* No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says

== Product Owner ==
* Is vaguely defined in Ken Swabers SCRUM books
* Is optional (not required), usually it is the client themselves or done by the Scrum Master
* Probably the most important role in the Scrum Team
* The great team may produce great software very quickly, but the software may be absolutely useless for the users
* Usually involves a lot of politics
* Talks to:
** Clients/Users of the application
** CEO
** Managers
** CTO
** Architects, Analysts, etc...
* Should be "the Biggest Pig" in the whole Team

== Product Owner Responsibility ==
* Requirements gathering (business analysis)
* Deciding what should be done first (prioritization)
** Business Value
** Technical aspects (dependencies, technology development, etc..)
* Answering team members questions on-the-fly
* Backlog Grooming (maintenance)
* Synchronizing Backlogs between teams
* Long Term Estimation (as opposed to Sprint Estimation)
* Long Term Forecasting
* Release Management
* Costing

== PO as the most important role ==
* Good product needs good specification
* Client expectation may be unrealistic, PO needs to explain that (politics)
* Team member need to clearly understand specification

== Quiz ==
Who should be the Product Owner in the most optimistic scenario?

== Who should be the Product Owner in the most optimistic scenario? ==
* The client themselves or a representative of the client
* Application Users
* Product Manager
* Tester
* Business Analyst
* Project Manager
* Developer

== Quiz ==
Why is the Product Owner the Most Important Role?

== Product Owner in a company ==
* Corporate Strategy
* Business Unit Strategy
* Strategic Objectives
* Project Mission, Vision and Objectives
* Software Design and Enterprise Architecture
* Software Development
* Testing

== Product Owner and traditional roles ==
* Part Product Manager
* Part Project Manager
* Part Leader
* Part Business Analyst

== PO as Product Manager ==
* Understanding the business needs for their particular product(s)
* Talking to customers gathering information about their wishes
* Communicating outward regarding team, product, and project “state” to customers and stakeholders
* Creating a shared vision for where the market is going and how to leverage that opportunity
* Translating that vision into the features and dynamics for a product and mapping it into “chunks or themes” for release

== PO as Project Manager ==
* Forward thinking of Product Roadmap perspective
* Guide work iteration tempo as it relates to the forecast vs. team velocity
* Release schedule building
* Planning towards market release timing
** quality goals and testing
** documentation
** support training, sales training
** marketing preparation
** operations and deployment
* Creating a series steps leading to a sound release point

== PO as Leader ==
* Focal point within the team
* Motivating team members by providing compelling goals and objectives
* Making hard choices on priority and business value
* Guiding and listening to the team in finding creative ways to deliver more value with less scope and effort
* Defending their team and removing relevant impediments
* Coming to understand what their team’s strengths are and leveraging them to advantage in project workflow

== PO as Business Analyst ==
* Requirement writing, defining artifacts (User Stories, or Requirements)
* Often defining acceptance tests and measurements for Done-Ness
* Fostering collaboration between architects, developers, testers, and themselves

== The Product Owner ==
Ken Schwaber stated that there is “Only ONE Product Owner”

== Strategy ==
* Corporate Level Strategy
* Mission, Vision and Value
* Business Unit Strategy
* Products
* Markets
* Consumers segmentation
* Packaging
* Localization
* What, Who, Why, etc...

== Defining Users of the Application ==
* Age
* Occupation
* Language (Natives/Non-natives)
* Gender
* Computer Skills (proficient users)
* Mouse/Keyboard preference
* Motivation (why they are going to use the site, benefits)
* Sales channel, buying behaviour, what is profitable what is not

== Project Charter (Project Description) ==
* Business case and payback estimates
* Initial budget estimates
* Mission and vision; the motivation of the endeavour
* High level requirements (functional, non-functional)
* Views to constraints (schedule, cost, scope)
* Quality targets
* Architectural design, system performance goals
* Team staffing, space and tool allocation
* Risks and contingencies

= Backlogs =

== Product Backlog ==
* Pile of Product Backlog Items (PBI) User Stories, Epics, Themes
* User Stories may be more technical (related to re-factoring or architecture, maintenance, etc..) or business focus (functionality to the end user)
* Prioritized by business value, architecture (dependencies), technology maturity, etc...

== User Stories, Epics, Themes Examples ==
* Regression Testing to Meet Regulatory Coverage Goal of 95%
* Trainers can upload their CV
* Training Coordinators can search Trainers CV's content
* Business Processes are Managed in Open Source, Web-Based tool - find the tool

== Product Back Items ==
* Can be vague and broad
* Mostly focus on business value
* Explain the user perspective
* If possible should be technology independent
* Wish list rather than answers
* The rough time estimation should be from 4 hours up to 4 weeks
* Should be testable from UAT perspective

== Priority and the Level of details ==
* The lower the priority the less details are needed
* Some can be extremely vague e.g. Users can see related content (not defining what related content is or where a user will see it)
* Some authors recommend 20/30/50 rule, where
* 20% of stories are concrete and ready to roll
* 30% are epics which will be split out into smaller fine grained ones
* The last 50% are themes, vague ideas about long term product direction and people should not put much effort as they almost always change.

== The First Meeting ==
* Define a structure of further meetings
* Corporate Strategy
* Business Unit Strategy
* The Application Overview
* Users
* Non-functional requirements
* Main purpose
* All stakeholders
* Creating Roles (Actors in UML)
* Creating Epics (Business Use Cases)
* Defining Architecture and Technology
* Defining Non-functional requirements
* PRIORITIZE EPICS

== Epic (High Level Business Use Case) ==
''Trainer and Delegate can negotiate the date of the instructor-led on-line course in the system without a training coordinator involvement''

* Do not contain the test part
* Is abstract on purpose
* Intentionally short
* Do not answer "How" question, only "What"

== Workshop ==
* Choose the project you want to work on (if consensus cannot be reached, the trainer will choose)
* Choose people to discuss the product backlog in the first place (who are those people?)
* Using Excel or other spread sheet create a product backlog
* Define Primary Actors (roles)
* Everyone separately writes an Epic
* Discuss the Epic in a group
* (optionally) Use an UML tool, write use cases and scenarios

== Writing Stories (The 3 C's) ==
* Card
** represents the Story Card itself, either a 3x5 index card or Post-it Note that represents the User Story
** written on the card note is the Story—simply one or two sentences that captures the requirement
* Confirmation
** acceptance Tests for the story
* Conversation
** conversations that surround the story ** during its development
** the business context
** the technical landscape
** design and construction steps (Spring Backlog)

== A Story Framework ==
* As a <role>
* I want <system behaviour >
* So that I realize <some business value>
* And can see that it does <example>

== A story example ==
As a dog owner,
I want to sign-up for a kennel reservation over Christmas so
that I get a confirmed spot
* Verify individual as a registered pet owner
* Verify that preferred members get 15% discount on basic service
* Verify that preferred members get 25% discount on extended services and reservation priority over other members
* Verify that past Christmas customers get reservation priority
* Verify that declines get email with discount coupon for future services

== Writing Stories ==
* Think of the end user of the software!
* Go through the process (scenario) with them!

== Story Characteristics (INVEST acronym) ==
* '''Independent''': avoid dependencies
* '''Negotiable''': clear enough, from a business and value perspective, so that you, the team, and stakeholders can individually negotiate each Story
* '''Valuable''': prioritize-able in the order that it brings value (priority) to the business and customer
* '''Estimate-able''': their size is estimated so that the Product Owner understands the Level of Complexity and Level of Effort associated with each
* '''Small''': can be completed by an individual or a small group within 2 to 5 days
* '''Testable''': clearly delineate conditions

== User Story vs. Use Case + Scenarios ==
* User Story can be more vauge
* No strict framework (some Use Cases or Scenarios can comply to methodology)

== Scenario ==
* Known from heavy methodologies
* Used them only for things which are very vague for the team, don't create superfluous documentation
* Usually happy-day scenario + one not-so-happy day scenario are enough
* DON'T USE FULL SENTENCES

== Scenario Example ==
* Redeem the Voucher
* Pre Conditions
* User has to be logged in
* Post Conditions
* User redeemed the points
* The reward has been sent
* Steps
* User click on "Redeem Voucher" link
* Choses the reward
* Confirms by clicking the "Confirm" button

= Prioritization =

== Backlog Prioritization Factors ==
* Business Value
* Time Value
* Dependency Constraint
* Technical Constraint
* Political Constraint
* Technological Development

== Business Value ==
* Business value expands concept of value of the firm beyond economic value (economic profit, Economic value added, and Shareholder value)
* Includes
** employee value
** customer value
** supplier value
** channel partner value
** alliance partner value
** managerial value
** and societal value
If the monetary value isn't the most important one for your organisation, choose different kind of value (e.g. number of lives saved, accidents prevent, etc...)

== Business value ==
* Clear for new functionality
* Research spikes, re-factoring work,training, bug fixes, etc. the distinction isn’t quite so clear, but it’s equally important
* Technical User Stories can be marked or keep separately in the backlog
* It is sometimes incredibly hard to explain the value of re-factoring or improving the environment (like testing a new IDE) to the management or the client

== Time Constraint ==
Project schedule perspective (task dependency)
Infrastructure testing should be done before the release
Deferring any critical bug fixes until the final Sprint when developers don't remember the code
Tuning graphic design may be less expensive when it is done at the end of the release

== Dependency Constraint ==
* User stories should be independent or loosely coupled
* There will be strong dependencies that come into play
* Little sense to allow customer to order the book if there is not payment system in place
* The architecture should be thought through at the very beginning
* Integrating two modules if one can be replaced in the future doesn't make sense either

== Technical Constraint ==
* Architecture dependencies (e.g. the SOAP interface should be defined before any of consumers is developed)
infrastructural dependencies
* Ease of implementation (web vs desktop)
* Ease of testing
* Team members availability

== Political and Marketing Constraint ==
* Show glitzy stuff makes sense if you want to get more funding
* Sometimes it is better to please people who are going to fund the project, even if it is not good from long-term perspective
* Users may want to see things which may not be relevant to the business model, but will keep them using the service

== Technological Development ==
* The technology develops quickly, waiting for a new realease of library a month makes more sense than writing it from scratch
* Optimisation can be postpone until hardware will be cheaper
* New version of compiler will solve the performance problem, etc...

== Group Based Prioritization ==
* If stories are related, it may be good idea to group them and assign priority to a group rather than an individual stories
* It saves time and enabled easier re-prioritization of the Backlog

== Priority Poker ==
* Everyone selects priority (from 1 to 9 for example, where 1 is the highest)
* Two extreme people explain why they thought this way
* Discussion
* Optional re-vote
* You can play poker for estimated time and estimated business value

[[File:Planning Poker Cards.png|200px]]

[[File:Planning Poker Game.png|200px]]

== Quiz ==
* What is a rule of thumb if you want to answer a question:
* What stories should be done first?

== Priority and Estimation ==

(Business Value)/(Estimated Time) ration

* speed (velocity) of delivering value
* ration is one of the most important factor when prioritizing
* In other words, small change can make a huge difference
* Time estimation can and should influence priority
* Longer stories can be postpone in order to get more impetus to the project (see Political constraint)
* Very long stories (30 days or more) can be split and prioritize differently

== Quiz! What should I do first? ==
{| class="wikitable sortable" border="1"
|+ Backlog
|-
! scope="col" | Name
! scope="col" | Estimated Time
! scope="col" | Business Value
|-
| US 1 || 20 || 5
|-
| US 2 || 5 || 1
|-
| US 3 || 2 || 2
|-
| US 4 || 17 || 4
|-
| US 5 || 1 || 3
|}

== High Level Estimates ==
* Time
** Saves work for translating the points into time
** Can make developers to underestimate the complexity
** Good developer does things fast
* Points
** Capture relative relation between the complexity of the use cases
** Focuses on complexity rather than time
** Good developer deals with complex issues

== Two Level Agile Planning Abstraction ==
* High Level Planning (Product Backlog level)
** Stories are captured and estimated
** Release plans are forecast at the velocity level for sets
* Low Level Planning (Sprint Backlog level)
** This is where Stories are broken down into tasks
** Where the true effort for each Sprint is surfaced
** Where true time emerges, less at an estimate level, more important at the actual outcomes reflecting the team’s commitment
** ALL estimates become more accurate (triangulate) over time

== Sprint Planning Meeting ==
* Split Epics into Stories
* Create Scenarios
* Add technical Stories
* Estimate (Estimation (Planning) Poker)

== Accurate and Precise Planning ==
* What is the difference of being prices and accurate? Give an example?
* Avoid Precision focus on accuracy
* Avoid spending too much time on planning, your estimates are estimates only and error is unavoidable

== Grooming (Maintaining) the product backlog ==
* Product backlog is constantly changing
* Change can contain:
** Adding more description and clarification
** Removing items
** Adding items
** Re-prioritizing
** Changing estimates
** Splitting Epics into User Stories
** Combining them into groups and themes

== Who should understand backlog ==
* All team members should be familiar with PB
** They can help if they know some solutions
** They get the bigger picture
* Stake holders and especially clients
* When everyone knows the backlog, the vocabulary is coined and people can speak "one language"

= Other Related Issues =

== Setting out sprint goals ==
* Connected to project or corporate goal
* Explain the motivation of the work (especially important with very technical projects where it is not obvious)
* Prevents people doing the wrong things because they didn't understand the task

== Sprint Goals Examples ==
* Migrate all legacy database tables and functionality into the new application in order to allow people to use one system so they don't have to switch windows in the next 30 days
* Make the average page response time below 300ms

== Done-ness criteria ==
* Code is complete
* Code has been revised
* Code checked-in
* Unit tests were defined where appropriate; nothing less than 40% coverage
* Acceptance tests passed
* Demonstrated functionality to Product Owner— received interim “Thumbs Up”

== Release Criteria ==
* Quality Criteria
** test coverage
** acceptable bug levels and actions
** workaround guidelines
* Functional Criteria
* Process Criteria
** steps necessary to prepare the organization to properly deploy and support the customer with the release
* Performance Criteria
** performance
** minimal platform support levels
** interoperability checks

== Scrum of Scrums ==
* Importance of Architecture
* Shared product owner vs. PO per team
* Chief PO
* Dealing with Project using other methodologies

== Outsourcing and Remote work ==
* Need for tools
* PERMANENT video link (no need for calling)
* It's better to beg for forgiveness than ask for permission

== Tools ==
* Scrummy
* Wiki
* Rally
* VersionOne
* Microsoft TFS
* ScrumWorks
* Jira + Greenhopper
* Redmine
* XPlanner

== Product Owner Myths ==
#. They’re not a member of the team
#. They never have enough time
#. Business value is the only determinant of priority
#. They know everything the customer needs or wants
#. They’re the only one contributing to the Product Backlog
#. They have to be full-time
#. There can be only one
#. It’s always the Product Manager
#. They make technical decisions or tell the team how to approach their work
#. They don’t do Sprint work

== Waste in Software Development ==
# Partially done work
# Extra features (Gold Plating)
# Relearning
# Hand-off
# Task Switching
# Delays
# Defects

== Books ==
[[File:SCRUM Product Ownership - Balancing Value From the Inside Out - Book.jpg]]

Scrum Product Owner - Revision history

84.107.249.12: /* Priority and the Level of details */