Recommended
Recommended
More Related Content
Similar to Ready, Steady, Sprint
Similar to Ready, Steady, Sprint (20)
More from XPDays
More from XPDays (20)
Recently uploaded
Recently uploaded (20)
Ready, Steady, Sprint
- 1. Ready, Steady, Sprint Held by, Ahmed Helmy Ready Steady Sprint
- 3. What would you do before first sprint? https://www.menti.com/d324whqbdr Go to www.menti.com and use the code 2153 7304
- 5. Team Readiness image: Freepik.com Teach Scrum Play Games Team Canvas
- 6. “In teamwork, things you don’t talk about tend to matter the most” http://theteamcanvas.com/learn/
- 8. Tuckman’s Stages Team Effectiveness Time • Show off • Me! Forming • Honeymoon is over • You! • Blaming • Fights Storming • Us! • Team Norming • Collective Result Performing
- 9. You can’t just put a group of people together and expect them to be a team; it takes time for them to sort out how to work together
- 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
- 14. Architecture Development Framework Testing Framework Source Control DevOps Environment Setup HLD TFVC/ git Repos Branching Strategy PR Workflow CI CD Watch out for The Technical Readiness LLD
- 16. Agree or Disagree! Release Planning https://www.menti.com/d324whqbdr Go to www.menti.com and use the code 2153 7304
- 17. Sprint 1 Sprint 2 Sprint 3 Sprint 1 Sprint 2 Sprint 3 Release 1 Release 2 Definition of Ready Definition of Done Release Planning
- 20. Thank You!
Editor's Notes
- 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 Months The items you’d like the team to do within the next three months will make up your product backlog. Items You’ll Never Do The 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 backlog Every 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 Months If 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 It A 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
- Environment Setup: Dev, Test, Staging, Production. Development Framework: .NET Core, Java, React, ABP, ASP.NET Zero, Visual Studio, VSCode, Eclipse Testing Framework: SpecFlow, Robot Framework, Selenium, Jmeter, X-Unit, N-Unit, Moq Architecture: HLD, LLD, Onion Architecture, Clean Architecture, DDD Source Control DevOps: CI/CD Pipelines, SonarQube, Containers, Docker, Kubernetes
- 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