#6 :: The Scrum Guide through different perspectives

prespectives

Recently i’ve decided to try the Professional Scrum Master certification provided by scrum.org. I have to admit that it’s not an easy assessment! It requires that you have a good understanding of roles, events, artifacts, rules as described in the scrum guide and it requires that you have made your reflection on all these aspects of scrum if you would like to go one step further!

I would like to share with you that i really enjoyed the whole process! Working for more than four years with the scrum framework, this challenge gave me the opportunity to refresh my knowledge, reflect on what i can improve in our work environment and make me feel much more confident with the framework!

While studying it helped me a lot to read the scrum guide through different perspectives, so i decided,  somehow to “re-write” most of the scrum guide contents, wearing different lenses! Hope it help you as well!

through the product owner perspective

in general as PdO

  • i am responsible for maximising the value of the product and the work of the development team
  • i am the sole person for managing the product backlog that includes:

clearly expressing PBI; ordering the items in the PB to be achieve goals and missionsoptimise the value of the work the development team performsensuring that the PB is visible, transparent, and clear to all and shows what the scrum team will work on nextensuring the development team understands items in the PB to the level needed.

it is ok some of the above work on product backlog management to be done by the development team…as long as i remain accountable!

  • i am just one person! not a committee! however i might represent the desires of a committee in the product backlog…but if you need to change the priority of any item you must address me!
  • i own my decisions and i need the entire organisation to respect my decisions. I make my decisions visible in the content and the ordering of the PB. No one is allowed to tell the development team to work from a different set of requirements.
  • Normally, i am not considered as part the development team (3 to 9 members), unless i am executing work of the sprint backlog!
  • i decide whether i will release or not  a new sprint increment that should be in useable condition

during the sprint

  • as more is learned during the sprint, it might be a need to collaborate with the development team, to clarify and re-negotiate the sprint scope (if the work turned out to be different than the development team expected ).
  • i am the only one that has the authority to cancel a sprint if the sprint goal becomes obsolete, although i might do that under the influence from the stakeholders, the development team or the scrum master. When a sprint is cancelled, if there is part of the work that is potentially releasable, typically i will accept it.

@sprint planning

  • i discuss the objectives that the sprint should achieve and the PBI that, if completed in the sprint, the sprit goal would be achieved.
  • as member of the scrum team we collaborate on understanding and planning the work of the sprint.
  • as a member of the scrum team we will craft the sprint goal!
  • i can help to clarify the selected PBI and make trade-offs.

@sprint review

  • as member of the scrum team, i collaborate with the other roles and the key stakeholders that i have invited in sprint review, about what was done in the sprint. Based on that and any changes happened in PB during the sprint, we collaborate on the next thing that could be done to optimize value, providing in that way valuable input for the subsequent sprint planning.
  • i explain what PBIs have been “done” and what has not been “done”.
  • i discuss the PB as it stands and if needed, i project likely completion dates based on the progress to date.
  • all together we review how the marketplace or potential use of the product might have been changed, what is most valuable to do next, we review the timeline, budget, potential capabilities and marketplace for the next anticipated release of the product.

@sprint retrospective

  • as member of the scrum team i participate in the sprint retrospective since it is an opportunity to inspect (people, relationships, process, tools)  and create a plan for implementing improvements in the next sprint.

PdO & Product Backlog

  • i am responsible for the PB, including its content, availability, and ordering.
  • i track the sum of total work remaining to reach a goal at least in every sprint review. I compare this amount with work remaining at previous sprint reviews to assess progress toward completing projected work by the desired time for the goal. I keep this information transparent to all stakeholders.
  • as member of the scrum team, we decide how and when product backlog refinement is done (should consume no more than 10% of development team capacity)
  • in product backlog refinement (an ongoing process), i collaborate with the development team on PBI details, and PBI are reviewed and revised. However i can update at any time the PBI or at my own discretion.
  • in product backlog refinement (an ongoing process), i may influence the development team on PBI estimates, by helping it understand and select the trade-off.

PdO & definition of “Done”

  • as member of the scrum team, i must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
through the development team perspective 

in general as Development Team

  • we consist of professionals who do the work of delivering potentially releasable increment of “done” product at the end of each sprint.
  • Only our members create the increment.
  • we are structured and empowered by the organization to organize and manage our own work
  • we are self-organised; we decide how to turn product backlog into increments of potentially releasable functionality
  • we are cross-functional; we have all the skills as a team necessary to create a product increment.
  • we have not titles for our members other than developer, regardless of the work being performed by the person.
  • we have no sub-teams, regardless of particular domains that need to be addressed like testing or business analysis.
  • we might have as individual members specialized skills and areas of focus, but accountability belongs to the development team as a whole.
  • we are between 3 to 9 people (excluding PdO and ScM). less than 3 members decrease interaction and results in smaller productivity gains and we may encounter skills constraints during the sprint, causing our team to be unable to delver a potentially releasable increment. Being greater than 9 members, requires too much coordination and generate too much complexity for the empirical process to manage.
  • no one is allowed to tell us to work from a different set of requirements, and we are not allowed to act on what anyone else says.

during the sprint

  • as more is learned during the sprint, it might be a need to collaborate with the PdO, to clarify and re-negotiate the sprint scope.
  • in order to satisfy the sprint goal, we implement the functionality and technology required. if the work turns to be different that we expected, we collaborate with the PdO to negotiate the scope of sprint backlog within the sprint.
  • we may influence the PdO to cancel a sprint (refer to PdO perspective).

@sprint planning

  • belonging to the scrum team we collaborate on understanding and planning the work of the sprint.
  • we work to forecast the functionality that will be delivered during the sprint.
  • the number of selected PBI for the sprint is solely up to us!
  • only we asses what we can accomplish over the upcoming sprint!
  • belonging to the scrum team we craft a sprint goal. it is an objective that will be met within the sprint through the implementation of the PB
  • sprint goal provides guidance to us on WHY we are building the increment and it gives us some flexibility regarding the functionality implemented within the sprint. The sprint goal could be one coherent function based on the selected PBIs or can be any other coherence that causes us to work together rather than on separate initiatives.
  • having set the goal and selected PBI for the sprint, we decide how to build this functionality into a “done” product increment during the sprint.
  • we usually start by designing the system and the work needed to convert the PB into a working increment.
  • we plan enough work (varying size or estimated effort) during the sprint planning to forecast what we believe we can do in the upcoming sprint. The work we plan for the first days of the sprint is decomposed by the end of the sprint planning , often in units of one day or less.
  • we self-organize to undertake the work in the sprint backlog, both during the sprint planning and as needed throughout the sprint.
  • if we determine that we have too much or too little work we may renegotiate the selected PB items with the PdO.
  • we may also invite other people to attend in order to provide technical or domain advice.
  • by the end we should be able to explain to the PdO and and ScM how we intend to work as self-organizing team to accomplish the sprint goal and create the anticipated increment.

@daily scrum

  • we use this event to synchronise our activities and create a plan for the next 24hours. We inspect the work since the last daily scrum and forecast the work that could be done before the next one. we inspect how work progress is trending toward completing the work in the sprint backlog. By doing that we optimize the probability to meet the sprint goal.
  • each development team  member explain

what he/she did yesterday that helped our development team meet the sprint goal; what he/she will do today to help the development team meet the sprint goal; if he/she see any impediment that prevent him/her or the development team from meeting the sprint goal.

  • we should understand everyday how we intend to work as a self-organizing team to accomplish the sprint goal and create the anticipated increment by the end of the sprint.
  • we often meet immediately (all or part or our development team) for detailed discussions, or to adapt, or replan, the rest of the sprint’s work.
  • we are responsible for conducting the daily scrum.
  • we only participate in the daily scrum.

@sprint review

  • belonging in the scrum team, we collaborate with the other roles and the key stakeholders about what was done in the sprint. Based on that and any changes happened in PB during the sprint, we collaborate on the next thing that could be done to optimize value, providing in that way valuable input for the subsequent sprint planning.
  • we discuss what went well during the sprint, what problems we ran into, and how those problems were resolved.
  • we demonstrate the work that it has been “done” and answer questions about the increment.

@sprint retrospective

  • belonging in the scrum team we participate in the sprint retrospective since it is an opportunity to inspect (people, relationships, process, tools)  and create a plan for implementing improvements in the next sprint.

Development team & Product Backlog

  • belonging in the scrum team, we decide how and when product backlog refinement is done (should consume no more than 10% of our development team capacity)
  • in product backlog refinement (an ongoing process), we collaborate with the PdO on PBI details, and PBI are reviewed and revised.
  • PBI that can be “done” form our development team within ones sprint are deemed “ready” for selection in a sprint planning.
  • we are responsible for all estimates.

Development team & sprint backlog

  • this is our forecast about what functionality will be in the next increment and the work needed to deliver that functionality into a “done” increment.
  • the sprint backlog makes visible all of the work that we identify as necessary to meet the sprint goal.
  • we modify the sprint backlog throughout the sprint and the sprint backlog emerge during the sprint. This happens as we work through the plan and learn more about the work needed to achieve the sprint goal. Changes in sprint backlog progress, which is a plan with enough details, can be understood in the daily scrum.
  • if new work is required, we add it to the sprint backlog.
  • as work is performed or completed, the estimated work is updated.
  • when elements of the plan/sprint backlog are deemed unnecessary, they are removed.
  • only we can change the sprint backlog during a sprint.
  • the sprint backlog, which is a highly visible, real time picture of the work we plan to accomplish during the sprint, belongs solely to us.
  • at any point of time we can track the total work remaining (at least for every daily scrum) to project the likelihood of achieving the sprint goal. By tracking the remaining work, we can manage our progress.
  • at the end of the sprint, the new increment must be “done” and meet our scrum team’s definition of “done”.

Development team & definition of “done”

  • belonging in the scrum team, we must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
  • the same definition of “done” guide us in knowing how many PBIs we can select during the sprint planning.
  • we deliver an increment of product functionality every sprint. This increment is useable, so the PdO may choose to immediately release it or not.
  • belonging in the scrum team, if the definition of “done” for an increment is part of conventions, standards or guidelines of the development organization, we must follow it as minimum. If “done” for an increment is not a convention of the development organization, we, as development team of the scrum team, must define a definition of “done” appropriate for the product. If there are multiple scrum teams working on the system or product release, the development teams  on all of the scrum teams must mutually define the definition of “done”.
through the scrum master perspective 

in general as ScM

  • i am responsible for ensuring scrum is understood and enacted. I am doing this by ensuring that the scrum team adheres to scrum theory, practices and rules.
  • i am a servant-leader for the scrum team.
  • i am helping those outside the scrum team to understand which of their interactions with the scrum team are helpful and which are not. I am helping everyone to change these interactions to maximize the value created by the scrum team.
  • i am serving the PdO in several ways, including:

finding techniques for effective PB management (see in PdO perspective); helping the scrum team understand the need for clear and concise PB items; understanding product planning in an empirical environment; ensuring the PdO knows how to arrange the PB to maximize value; understanding and practicing agility; facilitating scrum events as requested or needed.

  • i am serving the development team in several ways, including:

coaching the development team in self-organization and cross-functionality; helping the development team to create high-value products; removing impediments to the development team’s progress; facilitating scrum events as requested or needed; coaching the development team in organizational environments in which scrum is not yet fully adopted and understood.

  • i am serving the organization in several ways, including:

leading and coaching the organization in its scrum adoption; planning scrum implementations within the organization; helping employees and stakeholders understand and enact scrum and empirical product development; causing change that increases the productivity of the scrum team; working with other scrum masters to increase the effectiveness of the application of scrum in the organization.

  • i am not telling the development team how to turn PB into increments of potentially releasable funtionality.
  • Normally, i am not considered as part the development team (3 to 9 members), unless i am executing work of the sprint backlog!

during the sprint

  • i may influence the PdO to cancel a sprint (refer to PdO perspective).

@sprint planning

  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach the scrum team to keep it within the time-box.
  • as member of the scrum team we collaborate on understanding and planning the work of the sprint.
  • as member of the scrum team we craft a sprint goal.

@daily scrum

  • i ensure that the development team has the meeting.
  • i teach the development team to keep it within the 15-minute  time-box.
  • i enforce the rule that only development team members participate in the daily scrum.

@sprint review

  • as member of the scrum team, i collaborate with the other roles and the key stakeholders that i about what was done in the sprint, what to do next, so that to provide valuable input to subsequent sprint planning.
  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach all to keep it within the time-box (4 hours meeting for one month sprint)

@sprint retrospective

  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach all to keep it within the time-box (3 hours for one month sprint)
  • i participate as a peer team member in the meeting from the accountability over the scrum process.
  • i encourage the scrum team to improve (identify improvement to be implemented in the next sprint), with the scrum process, framework, its development practices to make it more effective and enjoyable for the next sprint.

ScM & transparency

  • i must work with PdO, development team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency.
  • i must help everyone apply the most appropriate practices in the absence of complete transparency.
  • i can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what being said, and detecting differences between expected and real results.
  • my job is to work with the scrum team and the organization to increase the transparency of the artifacts. The work usually involves learning, convincing, and change!

ScM & definition of “Done”

  • as member of the scrum team, i must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
through the rules perspective

general

  • scrum is a framework for developing and sustaining complex products.It is used to manage complex product development. It is not a process or a technique for building products; rather it’s a framework within you can employ various processes and techniques
  • scrum is founded on empirical process control theory, or empiricism and the three pillars as in every empirical process control implementation are

transparency: significant aspects of the process must be visible to those responsible for the outcome, defined by common standards so observers share a common understanding of what is being done

inspection: scrum user must frequently inspect scrum artefact and progress towards a sprint goal to detect undesirable variances.

adaptation: if inspection determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed myst be adjusted as soon as possible to minimise further deviation.

roles

  • consist of: PdO, development team, scrum master
  • scrum team are self organized and cross-functional. the team model is designed to optimize flexibility, creativity, productivity
  • scrum teams deliver “done” products iteratively and incrementally ensuring that a potentially useful version of working product is always available.
  • no one is allowed to tell the development team to work from a different set of requirements and the development team is not allowed to to act on what anyone else says.
  • only development team members create the increment and no one tells them how to turn product backlog into increments of potentially  releasable product
  • scrum recognises no titles other than developer.
  • scrum recognise no sub teams.
  • development team size is between three to nine people (excluding PdO and ScM)

events

  • four formal events for inspections and adaptation are prescribed: sprint planning, daily scrum, sprint review, sprint retrospective. These events are specifically designed to enable critical transparency and inspection.
  • all scrum events are time-boxed, such that every event has a maximum duration.
  • sprint
    • Once a sprint begins its duration is fixed and cannot be shortened or lengthened. All the other events may end whenever the purpose is achieved, ensuring and appropriate amount of time spend without allowing waste in the process.
    • sprint is a time-box of one month or less during which a “done” useable and potentially releasable product increment is created. sprints must have consistent durations throughout a development effort. A new sprint starts after the conclusion of the previous sprint.
    • during the sprint: no changes are made that would endanger the sprint goal, quality goals do not decrease, scope may be clarified and re-negotiated between the PdO and the development team as more is learned.
    • a sprint could be cancelled by the PdO when the sprint goal become obsolete.
  • sprint planning
    • sprint planning is time-box to a maximum of eight hours for one month sprint.
    • sprint planning answers the what can be delivered in the increment for the upcoming sprint and the how the work needed to deliver the increment be achieved
    • input to the sprint planning is the product backlog, latest product increment, projected capacity of the development team during the sprint, past performance of the development team.
  • daily scrum
    • is a 15-minute time-boxed event for the development team and only development team members participate in the daily scrum.
  • sprint review
    • is a four-hour time-boxed meeting for one month sprints.
    • the result of sprint review is a revised PB that defines the probable product backlog items for the next sprint. May also be adjusted overall to meet new opportunities
  • sprint retrospective
    • after the sprint review and prior next sprint planning and it is a three hour time-boxed meeting for one month sprints.
    • by the end of sprint retrospective the scrum team should have identified improvements that it will implement in the next sprint.

artifacts

  • product backlog
    • ordered list of everything that might be needed in the product and is the single source of requirements and any changes to be made to the product
    • it is dynamic and it is a list of all features, functions, requirements, enhancements, fixes
    • PBIs have the attributes of a description, order, estimate, value
    • one product backlog exists for multiple teams (grouping if items may be employed)
    • the various projective practices do not replace the importance of empiricism. In complex environments only what has happened may be used for forward looking decision making
  • sprint backlog
    • is the set of PB items selected for the sprint, plus a plan for delivering the product and realising the sprint goal.
  • Increment
    • is the sum of all PBIs completed during a sprint and the value of the increments of all previous sprints
    • at the end of the sprint, the new increment must be “done”, which means must be in useable condition and meet the scrum team’s definition of “done”.

definition of “done”

  • a shared understanding for everyone of what it means for a work to be complete, to ensure transparency
  • it is used from the scrum team to assess when work is complete on the product increment.
  • each increment is additive to all prior increments and thoroughly tested, ensuring that all increments work together.
  • any one product or system should have a definition of “done” that is a standard for any work on it.
in conclusion

scrum’s roles, artifacts, events and rules are immutable and although implementing only parts is possible, the result is not scrum. scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices

effort is good!

.nikos

must reading

The Scrum Guide (2013) – The Definitive Guide to Scrum: The Rules of the Game

Scrum – A pocket Guide

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

I Manage Products

PRODUCT MANAGEMENT BUILT BETTER, FASTER, STRONGER

Si Alhir (Sinan Si Alhir)

© 2016 Si Alhir (Sinan Si Alhir) — All Rights Reserved.

Assess your Agility - BETA

A framework to evaluate and improve your organization's agility

Lean Adaptive Leadership

Transforming technology organisations using lean and adaptive principles.

Systems Thinking and the Vanguard Method

Musings, discoveries and experiences

Control Your Chaos

That Scrum Girl on everything Scrum, Agile and Lean

The Product Owner Framework - BETA

Evaluate your skills and identify areas for growth

Digital Business Transformation

Inviting you to explore the world of Digital Business

Agile For Startups

Tools and Techniques for Tech - Startups .

Escape The Local Optimum

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Software Process and Measurement

Software Process Improvement and Measurement - Oh My!

Dave Nicolette

Effective software development and delivery

Arialdo Martini

Random notes about software

Agile By Culture

Doing Agile means being Agile

OutOfScopeException

Thoughts on software, code, philosophy and games

InnerActive Leadership

Partnering with you to find insights that lead to results!

Agile, Data, APIs, startups and more

Everything I find out about Agile, Data, Big Data, Data Science, APIs and of course Startups.

quantum shifting

think bigger, go further

Benjamin Mitchell's Blog

Helping IT teams & their managers deliver great software solutions

Diary of a ScrumMaster

Finding a path to a new way of working

An Ethical Island

How to Teach Without a Lecture and other fun

Mike Cohn's Blog - Succeeding With Agile

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Jim Highsmith

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

%d bloggers like this: