This week I took a refresher training on Scrum basics (from Kelley O’Connell, highly recommend you to take her course if it’s feasible ) so that I could reflect and appreciate the Scrum practices I do on regular basis and also start things that I have either stopped doing or never considered worthy! So here is my summary/takeaways. Hope you like it!
Scrum has become the most famous flavor of Agile practices and this post talks about what Scrum really is and how we can use it in our work environment.
Why Scrum , how teams use it and Scrum Framework…
The Problem:
Scrum – is taken from the word “Scrummage” (Rugby terminology). It’s the process where the play resumes after foul.
Historically, the Project plan was slated in the beginning and the entire team had to follow the plan without any variation. Well, in real life the project is highly unpredictable and its impossible to predict dates and how a project would unfold as time passes.
Agile Project management – allows a team to adapt to change in real-time. For example, I am building a page that displays 5 fields from a different system. In the best-case scenario, my plan would have tasks to include Development effort at my end + some development effort at the source system ending assuming they have to now expose those columns. However, after the first demo, it turns out the business actually needed values not from just 1 system but additional 2 other systems. Essentially, your project plan is no good and you have to plan each and every system differently. In such cases, it’s extremely important that we have an Agile project management process where we incrementally build as and when the scope is clear and the resources are available to take up the next piece of development.
In Rugby – the goal is to move the ball to the next line! – so why not in projects? Why can’t the project be broken down to concentrate on the next immediate milestone and not the Overall End Product!
Scrum Approach – allows teams to deliver milestones as small pieces.
The Agile Revolution:
Traditional Waterfall Project Manager : is like a weatherman who is predicting the weather for Next year and without luck, it is most likely going to fail.
Traditional Project plan – Good for Building where the plan is set in advance and you build as per the Blueprint. For imperial works Traditional is not a good way – for example (Software development, clinical studies ) where you fail and change the course of action (sometimes completely) to achieve the result.
Agile Manifesto :
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
Key Principles:
Work with business partners throughout a project – Every IT PM will vouch for this line. Traditionally it has always been the case where business shows up in the beginning on what they want and then show up at the end to tell what we missed !! A direct ongoing interaction on what they REALLY want is needed.
Measure success using completed software and not on meeting milestones – Working software that meets customer needs itself is the success
Allow teams to self-self-organize – Let the team handle the estimates and the actual effort for development, testing, and its timelines instead of defining it in the beginning through a Plan.
SCRUM:
The entire methodology is built to fail and fail fast !! – Historically 80% of the software failed.
Small scale focus and Rapid learning cycles. Fail fast and learn fast
Scrum framework in its simplest form:
- Product Owner priorities a backlog of work
- Team decides what can be taken up in next 2 weeks.
- Team develops and tests solutions until done.
- Team demonstrates its completed work.
- Team reflects on how it can improve.
The Framework:
3 Problems with Waterfall: Time, Cost and Scope . All 3 were finalised before the start of the project but by the Time project is delivered the business environment would have been changed and the project is mostly unsuccessful.
But in Agile Projects: Scope is Flexible but the Cost is Fixed. (ie: Build whatever you think is most valuable in the stipulated amount of time)
2 important Roles: Product Owner and Scrum Master.
- PO – Business representative dedicated to the team.
- Scrum Master – Dedicated role that protects the team and helps them improve.
Timing: Teams should deliver “Business approved and customer ready” products every two to four weeks.
Daily Standup: A team meeting is held each day.
Retrospective: Meeting for the team to reflect on what went well and how to improve.
Key Roles & Responsibilities
PO Responsibilities
- Acts as a full-time business representative. Need to show up every day and work as a contributor to the project.
- Review team’s work
- Ensures the highest value is delivered.
- PO should be in constant touch with other Business stakeholders to understand and be updated with the Business context.
- Updates the product vision on regular basis based on business needs.
Scrum Master Responsibilities:
- Protects the team and its processes.
- Keeps the team working at a sustainable pace. – Identify Burnouts ( Understand sustainability and open dialogue)
- Spokesperson of the Team. – example of how ?
- Helps remove any roadblocks – example of roadblocks.
- Holds the team accountable to the product owner. – Shows trends like team velocity , burn down chart to measure team strength.
Scrum Team:
Collaboration and communication is the Key.
- Colocate your team in the same area (if that’s an option).
- Video conferencing – Not every day but on a Weekly basis. I meet the team using teams video at least once a week.
- Chat rooms- I have teams channel for my Team (Dev, Testing, Architects ) so that everyone is aware of what is happening.
Team Composition:
- Always make sure you have a dedicated team. – Not having a dedicated team may result in loss of focus, accountability, burnout within members, etc.
- Ideal size – Based on research, Seven plus or minus 2 members.
- Includes team members with T- shaped skills – ex: Java Developer – Database analyst.
- Specialized skills like – Architects, DB analyst, and security analysts.. (Broad knowledge & Deep Knowledge)
Dealing with Conflicts:
- Establish Team Norms – Applied to all team members.
- Working Relationships – Ex: Treat everyone and their questions/suggestions with respect !
- Conflict Resolution – Ex: Sometimes we have to agree to disagree and proceed with the Group decision.
- Consensus options – Ex: Everyone should turn off phones during daily standup/ planning calls
The Planning !!
A- Talking Vision
Product Vision – (owner PO) Serves as guide for the team to reach
MVP (minimum viable product) – Develop product just enough to get user feedback.
- Allows for fast feedback loop
- Reduces scope creep
Example Vision for cafeteria app – Create an internal company app to help busy professionals have more time by providing a mobile/ desktop app where they can quickly order an affordable, tasty lunch and have it delivered or pick it up themselves.
Decomposing a Vision:
- Identify Themes to group similar work
- Ex: Profile,Order,Payment,Delivery
- Break themes into features
- Profile Theme
- Login (MVP1)
- Save passwords (MVP1)
- Recent orders (Phase 2)
- Favorites (MVP1)
- Recent Locations (Phase 2)
- Profile Theme
B – User Stories
Definition: Detailed, valuable chunk of work a team can deliver quickly. Anyone in the scrum team can create a US, usually drafted by PO.
Follow the below concept while writing user story:
- I – Independent – Can be delivered separately
- N – Negotiable – Can be rewritten or cancelled at anytime
- V – Valuable – Should be valuable to the stakeholder and Team
- E – Estimable – must be able to estimate in story points ie: Easily define hours to be burnt against this.
- S – Small – small enough to be completed within 1 sprint
- T – Testable – should be able to test it in 1 sprint.
Sample format: As a <user role>, I want <user requirement> so that <desired benefit>
Functional User story – Direct benefit to users
Example: As a mobile customer, I want to create a profile so that future order are faster to place.
Non-Functional user story: Indirect benefit to the user. Like a tech user story example: As a Developer, I want to upgrade the application server to the latest version so that products are built on latest app server.
Acceptance Criteria (AC): PO and team collaborate and come up with AC. Example of AC for the above US.
- Customer name is captured and saved
- Customer email address is captured and saved
- Customer phone number is captured and saved
- Customer password is captured and saved.
Additional AC – Invalid phone and Email id is rejected.
P.S: Writing good user story is challenging but gets easier with time.
C- Boundaries for Success
- Definition of Done: This is the minimum requirement for all the stories .
- Examples: The Story can be done if it has been tested in test environment. Or Code review is completed and all errors are taken care.
- Backlog prioritization:
- Grooming of the user stories are prioritized based on its value.
- Sprint Cadence:
- Can be 2 to 4 weeks overall. I always go with 2 weeks cadence.
- Too short can lead to bad quality and too long can have the team take a relaxed approach.
D- Estimation with Story points
- Relative Estimate – Rough size of work !! coming up with an estimate based on a previous story of similar nature. Helps in the relative estimate and not a commitment. Planning poker is a tool that I once used to come up with relative estimation for a sprint.
- Actual Estimate: Encourage to give actual estimates for the task within the user story.
E- Roadmap and Release plan
- Roadmap- Shows when themes will be worked on during any given time frame.
- Example: Start with Profile theme then go for ordering , payments and so on.. So , for Q1 – I am working on Profile theme, Q2 – Order Q3 – Payments and so on..
- Release Plan – Connects Roadmap to sprints. Scrum mandates us to have a Shippable product in the end of every sprints but we are not required to release it to customers at the end of sprint. So I can have 2 or 3 sprints to push the code to production.
- After initial sprints , team would know about the stabilized velocity. “Velocity” is the amount of story points delivered by the team in a particular sprint.
- To define a Release plan (points per release) lets say we have a velocity of 10 X 3 (no:of sprints before release) = 30 points per release.
The roadmap of the product generally consists of many such release plans like in the above example Q1 release to have a profile, Q2 release to have Order section, and so on…
The Execution:
Sprint Planning Meeting:
- Understand the story and its acceptance criteria.
- Post Definition of Done – For all the stories
- Testers and Dev have a good Q&A session and commit to delivering the work on time.
- Ensure Tasks within the User story are estimated accurately.
- Make sure to get a commitment from all the members (QA, Dev, etc) . If anyone has challenges then PM and SM should change the work they take for that sprint.
- This meeting repeats every sprint.
Ex: User Story 1 – 2 pts Task 1 – 3 hr Task 2 – 6 hr Task 3 – 3 hr
Estimating Rule of Thumb – Always estimate for ~6 hours, Other 2 hours are generally allotted for meetings, emails etc ..
Information Radiators:
Have below information radiators handy and shared with the team to understand the progress
- Project Vision
- Team Norms
- Team’s definition of done
- Release plan
- Taskboard and burndown chart.
Iteration Status:
- Sprint Stories
- Status of current tasks
- Completed tasks
Daily Scrum – (generally Set up by Scrum master)
- Principles behind the Scrum:
- Collaboration
- Communication
- Cadence
- Scrum Format:
- Entire Team joins
- Same time
- Every day
- Standup is Non-negotiable
- Iteration status chart is used as reference
- Tasks status are moved during the standup
- No details (Tech discussion/ defect analysis )to be shared of the activity – Only discuss overview of task.
- Assign 15 mins – should not be longer.
- Questions to be answered by Everyone –
- What did you do yesterday ?
- what are you going to do today ?
- Is anything blocking your progress ?
- Highlight risk and ask for help
Product Backlog: –
- PO owns the task of Backlog refinement and works with Stakeholders and keeps this updated.
- New features and stories are added.
- Stories are changed and removed.
- The team meets and reviews what new items have come up. You can use Edward Bono’s 6 thinking hats to brainstorm on what needs to be part of the subsequent sprint.
Backlog Grooming:
- Lasts 30 – 60 mins
- Occurs at the sprint’s midpoint
- PO explains new stories and the team ask questions
- Once all questions are answered PO prioritizes it for future Iterations
- At any point, the current iteration cannot be changed.
The Closing:
PO is responsible for Accepting the User story
- Sprint Review:
- Unaccepted or incomplete work is reviewed, prioritized, and moved to another sprint.
- The team agrees on what can be demoed to Larger stakeholders.
- Goal – what did we do !, what do we still need to do and what can be shown off.
- Demo
- Checkpoint where scrum team and PO shares the product with stakeholders
- Team directly communicates with stakeholders and gets feedback (praise for whats done and suggestions ).
- Great chance for the team and stakeholders to build relationship
- Shows Overall progress toward the final goal !!
- Pro Tip – not necessary in every sprint but Hold demos as often as possible.
- Retrospective:
- Meeting focused on team performance at the end of each sprint.
- SM is the facilitator of this session
- Safe environmetn
- Team members only
- Follow team norms
- Open Dialogue
Retrospective Agenda:
- What worked well?
- Focus on examples of great collaboration
- Achievements etc
- What did not work well?
- Focus on what you can change
- There is no point in discussing something that is not under our control.
- What can be improved?
- Focus on one or two items can be taken up in next sprint.
- SM holds the team responsible for their previous sprint improvement commitments
In Conclusion, the above is only the basics of what is needed to have a complete Scrum development model. I am sure there will be many occasions where you might have the compromise with a lot of activities. But as long as you can justify your actions against the core principles of Agile, be assured that you are on the right track and delivering the product that your customers need.
I hope you liked reading this article, do considering reading my other posts..
