Scrum Rules

Tushar Jain Tushar Jain

Tushar Jain

Artificial Intelligence and Generative AI trainer, thought leader, eager learner, and methodical focused on delivering integrated solutions to enable stakeholders to realize business objectives.

发布日期: 2017年8月2日
+ 关注
  • Scrum is a process framework/methodology
  • Scrum requires Agile mindset 
  • A Scrum team consists of a Scrum Master, a Product Owner, and Developers (members of the DevTeam)
  • Every Sprint is of same duration
  • Every Sprint is four weeks or less in duration
  • There are no breaks between two Sprints
  • The intention of every Sprint is “Potentially Shippable” deliverable
  • All meetings/ceremonies are time boxed


  • Every Sprint starts with Sprint Planning Meeting
  • The Sprint Planning Meeting facilitated by Scrum Master
  • The Sprint Planning Meeting is attended by Scrum Master, Product Owner, DevTeam members, and stakeholders
  • The Sprint Planning Meeting produces committed Sprint Backlog
  • In Sprint Backlog, the Product Owner defines Sprint Vision
  • The Sprint Planning Meeting has two parts.
  • The Sprint Planning Meeting is Timeboxed to two hours / week of Sprint duration
  • In Sprint Planning Meeting part one, Product Owner offers INVESTable PBIs to DevTeam and encourage them to commit for the current Sprint 
  • In Sprint Planning Meeting part one, Product Owner and DevTeam negotiate the scope of Sprint commitment 
  • In Sprint Planning Meeting part two, DevTeam break down contents of Sprint Backlog into SMART tasks
  • No additional stories to be added into Sprint Backlog after the Sprint Planning Meeting
  • No story deleted after the Sprint Planning Meeting from Sprint Backlog


  • Every day of team has Daily Standup at same time of day
  • The Daily Standup is not a status meeting but information sharing and asking for help meeting
  • The Daily Scrum is timeboxed to 15 minutes
  • In a Daily Standup, all team members remain stand up.
  • In the Daily Standup, every team member answers three questions only. No discussions.
  • All members of the team attend daily standup
  • If required after Daily Standup, team members may break into smaller groups

  • The Acceptance meeting is not an official meeting in the Scrum Guide.
  • The Acceptance meeting does not have time box or cadence. It is an impromptu meeting.
  • In an Acceptance meeting, one or more Developers and Product Owner meet.
  • Developer/s present a story and requests Product Owner to accept it as per criteria defined in Acceptance Criteria of this story.
  • Developer/s presents stories which have met Definition of Done (DoD).
  • The Product Owner may accept a story or decline the request
  • If story is accepted, it is marked as Done Done
  • If a story is not accepted, it remains in Sprint Backlog and DevTeam continue its effort on the story till it is accepted by the Product Owner in current Sprint or it goes back in Product Backlog for refinement after current Sprint is over.


  • The Sprint Review Meeting is conducted at last day of Sprint before Demo and Retrospective
  • The Sprint Review Meeting is for stakeholder feedback on the increment of current increment as well as product
  • The Sprint Review Meeting is facilitated by Scrum Master
  • All members of the team attend the Sprint Review Meeting
  • The Sprint Review Meeting may result in PBIs and/or items to be discussed in Retrospective
  • The Sprint Review Meeting is time boxed into two hours per week of Sprint duration


  • The Demo is not an official meeting in the Scrum Guide but most of the teams do it separate from the Sprint Review Meeting
  • The DevTeam demonstrates (show and tell) the delivery of current sprint to stakeholders
  • The Product Owner makes a call - Which PBIs to be demo-ed
  • The Demo may result in PBIs and/or items to be discussed in Retrospective
  • All stakeholders are invited to attend the Demo


  • Every Sprint includes Sprint Retrospective for the team to inspect and adapt
  • The team decides what to be leaked beyond four walls of the Retrospective meeting room.
  • Follow the Prime Directive of Retro
  • A Retrospective is strictly for the team. Only pigs are allowed, no chickens
  • In the Retrospective loop back the action items of previous Retrospectives
  • In the Retrospective conversation centered around three questions
  • All team members attend every Retrospective


  • Scrum Master is not a master of team but Scrum
  • No one reports to Scrum Master
  • A Scrum Master facilitates ceremonies
  • A Scrum Master is a Servant Leader
  • A Scrum Master works with only one Scrum Team
  • A Scrum Master is full-time role
  • The Scrum Master enforces time boxes for Scrum ceremonies and Sprint
  • A Scrum Master shields the team from interruptions
  • A Scrum Master is empowered to facilitate to tackle intra-team impediments
  • A Scrum Master is expected to work diligently to tackle organizational impediments
  • The Scrum Master has accountability to create and maintain the team’s Sprint burn down chart
  • The Scrum Master coaches the team to enhance effectiveness
  • The Scrum Master encourages the team to enhance efficiency and productivity by automation and better engineering practices
  • A Scrum Master continuously works with team to reflect
  • A Scrum Master has final authority within the team on the correct way to use the Scrum framework
  • A Scrum Master does not get involved in technical matters


  • The Product Owner owns Product Backlog
  • The Product Owner is accountable to keep healthy Product Backlog
  • All work to the team routed through the Product Manager
  • A team has only one Product Owner
  • No one in the team report to the Product Owner
  • The Product Owner is the go to person about product vision, goal, and functionality
  • The Product Owner accepts PBIs through out the Sprint
  • The Product Owner can cancel a Sprint midway
  • The Product Owner is always available to the team
  • The Product Owner keep on providing details on the PBIs as sought by devTeam
  • The Product Owner assigns business value to PBIs
  • The Product Owner interacts with DevTeam and stakeholders to keep Product Backlog DEEP enough to DIVE
  • The Product Owner has system analyst and business domain like expertise to understand pragmatic technological and functional realization of the product vision and goals
  • The Product Owner represents team in Demo
  • The Product Owner is accountable to refine Product Backlog on continuous basis
  • The Product owner do not add or delete items in Sprint Backlog in middle of a Sprint
  • The Product Owner owns Release burn down chart


  • In a DevTeam there is only one role - Developer
  • The DevTeam size is between 5 to 7 people
  • The DevTeam members are in continuous conversation with each other beyond Scrum ceremonies
  • The DevTeam estimates PBIs
  • The DevTeam strives to keep Technical Debt minimal and stable
  • The DevTeam commits in Sprint Planning keeping in mind the historical facts and current factors
  • The DevTeam is responsible to potentially shippable increment at the end of each Sprint
  • The DevTeam keep Product Owner in loop with respect to Technical PBIs
  • The DevTeam strives for automation in every aspect of development and maintenance
  • A DevTeam member can describe product with end to end functionality
  • A DevTeam member can describe product's high-level architecture
  • A DevTeam member actively seek to help of the team mates
  • A DevTeam member commits to do whatever it takes to reach each and every Sprint goal
  • A DevTeam member volunteer for a new task from the Sprint backlog as soon as it completes the current in hand
  • A DevTeam member is willing to learn any skill needed to help team
  • A DevTeam member work with all the team members to expand the Definition of Done
  • A DevTeam member seek direction for product vision and scope from the Product Owner
  • A DevTeam member never direct any other individual team member which task to work on next

  • Product Backlog is a ranked list of PBIs
  • Any one in the universe can add PBI to a Product Backlog but Product Owner prioritize
  • Product Backlog is an evolving list
  • Product Backlog is accessible to everyone


  • Sprint Backlog is a subset of Product Backlog to signify commitment of team for the current Sprint
  • Contents of Sprint Backlog are suggested by Product Owner but finalized by DevTeam
  • The order of delivery of items from Sprint Backlog is discretion of DevTeam
  • In the end of a Sprint, Sprint Backlog should be empty
  • Sprint Backlog is accessible to everyone


  • PBI is one which adds value to the Sprint deliverable directly
  • PBIs keep on evolving with rapid bursts when in Product Backlog but once in Sprint Backlog, evolution is much controlled
  • Most of the time PBIs are written as user stories
  • Each PBI has acceptance criteria 
  • The top PBIs are small enough (effort) that several can fit into a single Sprint
  • PBIs are invitations to conversations, not detailed specifications
  • Defects/bugs are PBIs


  • Scrum Board has four columns - Product Backlog, Sprint Backlog, Doing, and Done
  • Scrum Board is visual representation of work - To Be, Doing, and Done
  • Scrum Board helps to visualize and enforce WIP limit


  • Burn down chart is a graphical representation of remaining work in the current Sprint
  • Burn up chart is a graphical representation of completed work in the current Sprint
  • Burn up/down chart is updated daily


  • PBIs are 3Cs and INVESTable because of SMART tasks to make Product Backlog DEEP enough to DIVE

要查看或添加评论，请登录

Tushar Jain的更多文章

  • Should we fear AI?
    2024年1月2日

    Should we fear AI?

    Upon conducting an analysis encompassing social media, writable internet platforms (including blogs, podcasts, vlogs…

  • Baloney Detection Kit for an Agilest
    2020年6月25日

    Baloney Detection Kit for an Agilest

    Baloney Detection kit for Agilest is a set of cognitive tools and techniques that fortify the mind against falsehoods…

  • Four keys for Leaders to during a crisis
    2020年6月4日

    Four keys for Leaders to during a crisis

    In any crisis especially which has a significant component of uncertainty – people want leaders to provide the…

  • Artificial Intelligence for a Middle Schooler
    2020年2月20日

    Artificial Intelligence for a Middle Schooler

    A few days back my middle schooler asked what Artificial Intelligence is. At that moment I realized, how difficult to…

  • Scrum: Scrum Guide vs. SAFe
    2020年2月13日

    Scrum: Scrum Guide vs. SAFe

    Recently, Den Sunny published a write up on the difference between Scrum Guide’s Scrum and SAFe’s Scrum. In the end…

  • Are efficiency and productivity good enough?
    2019年12月24日

    Are efficiency and productivity good enough?

    Recently, I was at Newark airport, terminal C. From the terminal, only one airline operates United Airlines.

  • Design Thinking and Agile way of Software Development – Response
    2019年12月18日

    Design Thinking and Agile way of Software Development – Response

    Few of the fellow agilest pointed me toward a picture in which Design Thinking, Lean Startup, and Scrum are shown in a…

  • Design Thinking and Agile way of Software Development
    2019年12月10日

    Design Thinking and Agile way of Software Development

    There is a lot of buzz around Design Thinking in Agile circles. It seems lots of Agilest are sold to the idea of Design…

  • When not to use Scrum?
    2019年12月5日

    When not to use Scrum?

    When not use Scrum? When to use Scrum? What are the preconditions to use Scrum? The answer to the first two questions…

  • What is Agile?
    2019年12月3日

    What is Agile?

    Agile movement started by visionaries of Software development. With time, it has evolved beyond the IT and engineering…

社区洞察

其他会员也浏览了