Your first scrum sprint is most likely to fail, that’s why you need to be prepared to survive this hard sprint. Getting ready with a couple of pre-sprinting activities is a key that will help you to start your sprints with a proper plan and strategy to succeed. In this session “Ready, Steady, Sprint”, Ahmed will share insights about what activities need to be done before your first sprint and how each one will help you not only for the first sprint but for your whole journey.
11. From a Vision to a Backlog
Product Vision
High-level strategy of
the goals of your
product
Product Backlog
Tactical plan to
achieve that strategy
Definition of
Done
Definition of
Ready
DEEP INVEST
12. The 20/30/50 Rule
TOP MIDDLE BOTTOM
20% 30% 50%
Refined well enough
to be worked on
immediately
Suitable for a
productive discussion
with others
Contains only a
summary and possibly
a description
Your first scrum sprint is most likely to fail, that’s why you need to be prepared to survive this hard sprint.
Get ready with a couple of pre-sprinting activities is a key that will help you to start your sprints with a proper plan and strategy to succeed.
Share insights about what activities needs to be done before your first sprint and how each one will help you not only for the first sprint but for your whole journey.
𝗔𝗯𝗼𝘂𝘁 Ahmed Helmy
Software Consultant with 11 years of hands-on experience in different parts of the software industry.
Certified Scrum Professional ℠ (CSP-SM) - Scrum Alliance
Advanced Certified Scrum Developer (A-CSD) - Scrum Alliance
Certified Scrum Product Owner (CSPO) - Scrum Alliance
SpecFlow® Expert.
Author for IC-Agile Agile Programming (ICP-PRG) Course.
Founder of XP Days community group, where people meet to share knowledge about Agile methods and practice XP techniques.
I am very excited to be here as a speaker in RGS – Egypt and I would like to thank the organizing team
Ready
Team Readiness
Team Kick-off (Formulate a Team vision, Pick a Team Name)
Create a Team Contract (Agreements/House Rules)
Teach Scrum
Product Readiness
Backlog Refinement
Definition of Ready (Sizing and Estimates, Priorities)
Definition of Done (Test Approach/Frameworks/Process/Verification)
Technical Readiness
Ensure that environments are set up and any automation like CI/CD
Steady
Release Planning
Sprint
First Sprint
Team Kick-off activities
2-3 Days for a kick-start
Intense & serious investment
Important Signal
We’re taking time to become a team
Without exception, teams that spend this amount of time on starting up have a much smoother ride down the road and move to the performing phase far more rapidly.
Teach Scrum
Refresh the principles of Scrum
Misconceptions about what Scrum is and what it isn’t
Training
Highly interactive
Play games
Voicing disagreement is a sign that people care and feel involved (Productive conflict)
Kick-off games (Experiential Learning Activities)
Getting to know each other is half the work
Help the team create safety and familiarity
Examples
Introduce themselves as the superhero they’d like to be.
Visualize their strengths with LEGO
Create a personal profile card and avatar.
Line-up (self-organizing)
Goal
Break the ice
Get people out of their comfort zones
Careful
Facilitate these exercises in a lighthearted, fun way
Make it non-threatening for people to participate
It's perfectly fine if these exercises feel a bit awkward. It's better to cut through the awkwardness now, than having people feel restrained to participate later.
Team Canvas
The Team Canvas is Business Model Canvas for teamwork. It is a free tool for leaders, facilitators and consultants to organize team alignment meetings and bring members on the same page, resolve conflicts and build productive culture, fast.
Team manifest/contract
This helps to trigger the kind of discussions and conflicts that are part of the ‘storming phase’.
People & Roles What are the names and the roles of each member? – 5 mins
Team members introduce themselves
Common Goals What are the goals for the whole team? – 10 mins
Personal Goals What are individual goals of each team member? – 5 mins
Purpose What is the team's purpose: the Why behind your goals? – 10 mins
Values What are the core values that your share? – 10 mins
Needs & Expectations What are your needs and expectation from the team? – 10 mins
Rules & Activities What are the ground rules that you want to agree on? How are you going to communicate, make decisions, execute and give feedback? – 5 mins
Communication way (face-to-face/virtual )
Communication tool (email/slack/teams)
Strengths & Assets What are your strengths: things that would move you forward? – 15 mins
Weaknesses & Risks What are your weaknesses: things that would hinder you? – 15 mins
Pick a Team Name
During the norming phase, teams start developing an identity.
This identity consists of norms, values, and principles on how people want to work together.
A very simple but powerful exercise is to have teams come up with a name for their team during the Kickstart.
I usually ask pairs to come up with as many good names as they can think of, and then let the team dot-vote on the best name.
Although picking a name is always useful to promote a team identity, it works even better when there are more teams close to the team’s proximity.
Teams start taking pride in their name.
You can help a team move through the norming phase by having them think about what it means to be a good team.
-----------------------------------------------------------------------------------------
Create a Team Contract
Create clarity.
How are we going to work as a team?
Who is responsible for what?
When are the Scrum Events?
Clarity in roles and tasks is important for teams that are in the very early stages of formation (forming & storming).
Because the team does not yet offer a perfectly safe environment, members need to know what is expected of them. This is why I often help teams to formulate a Team Contract during their Kick-start. Using a couple of prepared sheets, I ask the team to (with my help) agree on a set of working arrangements:
Who are the members of the team? What do they bring to the team?
How are the roles distributed? Who is the Scrum Master / Product Owner, and who’s part of the Development Team? People not on the sheet are not part of the Scrum Team, and therefore do not participate during the various Scrum Events unless specifically invited;
When and where are the various Scrum Events? Who is expected to be there?
What happens when someone’s late to a Scrum Event, or unable to join altogether?
When are we — as a team — happy with a Sprint?
During the exercise, I generally move to the back of the room and let the team fill in the sheets together. This is an excellent way to observe team dynamics and get a sense of the phase a team is in. An example of a Team Contract is shown below. The sheets (I usually have two) are put on a visible spot where the team is working:
A good Scrum Team does not form within 1 or 2 sprints. It takes time to learn how to best work together.
Scrum Teams are self-organizing units that deliver working software. Team becomes increasingly capable to solve problems on their own.
This is usually three to five 2-week sprints down the road.
Vision is too vague, Goal is committed
Vision: Making Transportation Cheaper
Goal: New route discovery algorithm for shorter trips
Definition of Ready
Only Ready PBIs can be selected in a Sprint Planning
Product Backlog refinement
Break down and further defining Product Backlog Items into smaller more precise items.
Add details, such as a description, order, and size.
Great Product Backlogs are DEEP, and we INVEST in DEEP PBIs.
Definition of Done
A definition of "Done" to inspect and adapt over the lifetime of the product
The product backlog, in itself, will never be ready. The backlog is emergent, and evolves at least monthly (if not daily/weekly) - and as long as a product exists, so will its backlog.
Detailed
Estimable
Emergent
Prioritized
Independent
Negotiable
Valuable
Estimated
Small
Testable
Level Of Details
Sea-level
Kite
Cloud
Last Responsible Moment
The act of delaying a decision until the cost of not making a decision becomes greater than the cost of making a decision.
Hi Ahmed,I spent this morning cleaning up my personal to-do list. It had gotten a bit out of control. A few things had already been done (“order flowers for Valentine’s Day”). A few others were never going to happen. And some had become irrelevant (“get cash in advance of Y2K”).If your product backlog is anything like my to-do list or my product backlogs, it’s probably due for a spring cleaning. I suggest reviewing your product backlog at least twice a year. Just separate the items into three different categories: Items you’ll never do
Items you may do someday but not for at least three months
Items you’ll do within the next three months
Items You’ll Do Within Three MonthsThe items you’d like the team to do within the next three months will make up your product backlog.Items You’ll Never DoThe items you’ll never do should be deleted from your product backlog tool or otherwise thrown away. Remove items you’ll never do by reviewing the product backlog looking for items that are: - So old they’re no longer relevant - No longer desirable - Already in the product - So vague no one remembers why they’re in the backlogEvery time someone scans the product backlog looking for an item and has to read past worthless items such as these, they are wasting time. Save that time by simply deleting items you’ll never do.Or, if that’s uncomfortable, archive them. If the tool you’re using doesn’t have an archive feature, consider creating an empty project in the tool and moving items to that project. They aren’t deleted, but they’re at least out of sight and out of mind.Items You Won’t Do For at Least Three MonthsIf your backlog is like most, the majority of your items will fall between the extremes of needing them now and never needing them. If possible, I like to move these items off the product backlog, too.In some tools I can do that by hiding the items or setting a status value to one that isn’t shown in most views. In other tools I can move them into a new project created just to hold the backlog items that will be worked on in the future.I think of items moved here as being on the long-term product backlog. Maybe three months into the future isn’t really “the long-term.” But it’s far enough out that I don’t want the team being overly concerned with those items at the moment.As the team makes progress through items on the product backlog, there become fewer items on it. Any time I feel the product backlog has gotten pretty small, I’ll move another 10-50 items from the long-term product backlog onto the real product backlog. This prevents the cluttering of a team’s view of its work with items that simply aren’t important at the moment. Move those items out of sight to keep them out of mind.Go For ItA lot of folks are reluctant to ever remove things from the product backlog. But I encourage you to take the leap. Hit delete on some of them right now. Or archive items the best way your tool supports.Your team will benefit from increased focus on the items that are truly important right now. That increased focused will help you succeed with agile,Mike
Release planning helps you plan which product increments (versions) get released to the market and when.
This approach helps your team adapt to the unpredictable nature of software development.
The plan is a forecast related to the team’s velocity.
What is the purpose of Agile release planning?
The purpose of release planning within the Agile methodology is to ensure the product is always moving in the right direction and that logical releases are frequently happening.
It goes into more detail than a product roadmap (high-level scope and timeline).
But an Agile release plan doesn’t outline the work in each release. Instead, it batches iterations or sprints together into releases.
Old-fashioned executives fear going Agile means each version is a random collection of features. A release plan ensures that you create a coherent version of your product every time.
When to do release planning in Scrum?
Release planning comes after you’ve outlined your product vision and roadmap.
Planning and combining sprints into larger releases is often a good idea. If you have a lot of major items in your product backlog.
Most people don’t like change. Users take time to adapt to a new interface. So batching changes to the UX is a must.
Since the focus of Scrum is on shorter sprints, some teams work without release planning at all.
Instead, they just release the product increment. That keeps the focus on speed and adapting to the stakeholder needs at any moment.
Who is responsible for release planning in Scrum?
Product managers and C-suite execs.
Product owner and Scrum team must also participate.
The team can also be solely responsible for the plan depending on your company structure.
The Scrum team is often better connected to the current state of the software and all the different stakeholders, so they tend to lead the decision-making.
A Scrum Team
Product Backlog: an understanding of the product to be developed
A definition of "Done" to inspect and adapt over the lifetime of the product
Technical Readiness
Release Planning
Sprint Planning
A Sprint Goal to inspect progress towards
An agreed time-box for the length of the Sprint
A Sprint Backlog to inspect and adapt
Daily Scrum
Team will participate in the daily standup meeting and have a chance to note any obstacles they're encountering that are preventing them from completing their tasks.
The scrum master, with the help of other team members, will work together to remove those obstacles so the team can reach the agreed-upon definition of done for each story.
Sprint Review
A "Done" product increment to inspect
A Product Backlog to inspect and adapt
Sprint Retrospective
Give the team a more formal opportunity to talk about the challenges faced
Determine how they will improve in the upcoming sprint.
Tips
Inspect and adapt
Do not do too much in the first sprint
Deliver a small amount of business value.
Start backlog refinement early to prepare the team for sprint two.
"It's a good idea to try and get some business value out during the first sprint, even if it is just a 'hello world' type thing. The reason for this is we want to start engaging the stakeholders and the best way to do that is to deliver working functionality."
Sprint planning
Focus mainly on stories that will get your infrastructure and processes in place, but plan to have working software for the demo at the end of the sprint.
Keep the coding simple for this first sprint.
Coordinating the use of tools and processes and establishing high-quality practices from the start is important! this will set the stage for good coding practices going forward.
On the final day of the sprint, the team will host a sprint review and demo with their stakeholders.
Recognizing that having all the pieces in place to produce working software is a major accomplishment for the first sprint, one that is worth celebrating.
Bad first sprint
Pushed the idea of a "sprint commitment." Which means, no matter what, get the stories done. This resulted in testers working on Saturday and Sunday, only to find bugs. So the people felt pain AND management still felt like the team wasn't committed. Everyone lost!
𝗔𝗯𝗼𝘂𝘁 Ahmed Helmy
Software Consultant with 11 years of hands-on experience in different parts of the software industry.
Certified Scrum Professional ℠ (CSP-SM) - Scrum Alliance
Advanced Certified Scrum Developer (A-CSD) - Scrum Alliance
Certified Scrum Product Owner (CSPO) - Scrum Alliance
SpecFlow® Expert.
Author for IC-Agile Agile Programming (ICP-PRG) Course.
Founder of XP Days community group, where people meet to share knowledge about Agile methods and practice XP techniques.
I am very excited to be here as a speaker in RGS – Egypt and I would like to thank the organizing team