Scrum at a glance
Published in
6 min readJul 17, 2019
This story was a presentation about scrum and converted to story. It contains general aspects of Scrum.
Introduction:
Facts of software projects:
Most of the software project is not successful and there are lots of comics about software projects.
Software Development Process Models:
In order to manage software projects lots of process models tried.
- Hacking (No planning, analysis)
- Requirement-Code (Code -> Correct)
- Waterfall Model
- V Process Model
- Prototyping Model
- Rapid Application Development Model (RAD)
- Evolutionary Software Development Model
- Iterative Software Development Model
- Spiral Model
- Component Based (Reusable) Development Model
- Rational Unified Process(RUP)
- Agile Methods
Agile Software Development:
Last and most popular is agile.
Agility: Acting rapidly and coordinated against change
Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith, Agile Project Management
Why Agile?
- Managing changing priorities
- Quick deploy to production
- Increase in software quality
- Simplified software development process
Agile Manifesto 2001
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum:
Scrum is a framework for developing, delivering, and sustaining complex products
• Lightweight
• Simple to understand
• Difficult to master
Scrum Theory:
• Transparency
• Inspection
• Adaptation
Scrum in one picture:
Scrum Framework:
Scrum Framework consists of three main aspects:
Scrum Team and Roles:
Product Owner
- Customer Representative
- On the business side of the project
- Knows the business
- Manages stakeholders
- Identifies and prioritizes features
- Makes product decisions
- Manages the product
- Product Backlog is asked from him/her
- Product manager is one person
- Is responsible for maximizing the value of the product
Development Team
- Develops the product
- Self organizing team
- Cross functional (Each member does everything to deliver the product.)
- Single title developer
- Size: Small enough to act agile, large enough to produce a meaningful job in a sprint (3–9)
- All members must be fully dedicated to sprint
- Sprint duties:
- Task definition
- Effort estimation
- Product development
- Responsible for quality
- Process improvement
Scrum Master
- Slave Leader
- Team protector
- Problem Solver
- Scrum Guide
- Duties:
- Eliminating problems
- Preventing interruptions
- Formation of team phenomenon
- Supporting the Process
- Managing Management
Scrum Events:
Sprint
- Heart of Scrum
- Time-box (With a month and less limit)
- Useable, and potentially releasable product increment is created in it.
- Finished on time whether task are done or not done fully
- New sprint started just after the sprint finished
- During 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 Product Owner and Development Team as more is learned.
- Only Product Owner can cancel sprint
Sprint Planning
- All Scrum Team plans the stories(feature, task, requirements, etc.) to be done on the Sprint
- Time limit: For 1 month Sprint -> 8 hours
- Questions
- What can be done in this Sprint?
- How will the selected tasks be done?
- What?
- Sprint goal
- Tasks are discussed and understood by everyone
- How?
- Product Backlog -> Sprint Backlog
- Task are defined and estimations are done.
Daily Scrum
- 15 minutes limit
- At same place and on same time every day
- 24 hours task plan
- Sprint status is seen
- Scrum Master ensures that the Development Team makes the meeting, but it is the Development Team’s responsibility to conduct the Daily Scrum.
- Product Owner or another participant can participate meeting, but they do not interfere.
- Questions
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Sprint Review
- Team presents the sprint deliverables
- Time limit: For 1 month Sprint -> 4 hours
- Participants: Key stakeholders (product owner invites)
and Scrum Team - Elements:
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
Sprint Retrospective
- Monitor the process, Improvement
- Evaluating process and environment
- After the Sprint Review and prior to the next Sprint Planning
- Time Limit: For 1 month Sprint -> 3 hours
- Scrum Master masters.
- The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools
- Identify and order the major items that went well and potential improvements;
- Create a plan for implementing improvements to the way the Scrum Team does its work - Result:
- Things to do
- Things to continue to do
- Things to give up
Scrum Artifacts:
Product Backlog
- An ordered list of everything that is known to be needed in the product.
- (User Stories, Requirements, Jobs, To-Do, Functions, Fixes, Improvements)
- The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
- It is dynamic and open to constant change.
- Product backlog items features:
- Description
- Order
- Estimation
- Value
- Test definitions proving that they are completed according to Definition of Done
- Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items
Sprint Backlog
- set of Product Backlog items selected for the Sprint
- Development team selects the items
- No assignment to team
- Estimations are updated every day
- Development team can add, delete, change new tasks.
Increment
- sum of all the Product Backlog items completed during a Sprint and the
value of the increments of all previous Sprints - At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”
Definition of Done
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.
Common Scrum Problems and Mistakes:
- Not obeying the time limits
- Not clear Definition of Done
- Immediate emerging business requests
- Non-productive Sprint Retrospectives
- Less/ No / Long daily scrum
- Problem-Solving in the Daily Scrum
- Not well prepared product backlog
- Scrum Master acting as a Project Manager
- Unclear requirements
- Not Raising Obstacles Early Enough
References:
