Good ‘ole Scrum. Maybe you've heard of it, maybe you haven't. Maybe you've internet-stumbled your way to this post in hopes of figuring out what the heck this silly-sounding concept is.
Well, great news. Crema’s here to provide you with some considerations from our experience with this whole 'Scrum' thing. We hope it shines a bit of light into the complex world of new-age product development and management. Enjoy!
So, what is Scrum?
Scrum is a framework - that's truly what it boils down to at the end of the day. Some may feel that Scrum is a 'mindset' or even a ‘way of business'. As overwhelming as that may seem, frameworks can be implemented beyond just product development, so don't let that scare you or overwhelm you. In Scrum, we like to start small, so let's dive into the basics before we start drinking’ the Kool-Aid®
Scrum is to Agile like nice, cast iron skillets are to cooking: it's not the overall concept of what you're doing, but the distinct way in which you get your final product (may that be amazing cornbread or, in our case, a digital product).
In Agile development, we intentionally take things in iterative, palatable chunks of work. Scrum gives us proven tools, tips, and tactics to plan, develop, and deliver those chunks of work. There are many different types of implementation when it comes to Agile development (check out our other post Kanban vs Scrum for more) but when it comes to the default we use here at Crema, we love to lean into Scrum.
This framework encompasses Scrum Events (sans Kool-Aid®) that inspire:
- Collaboration for teams
- Data to estimate future progress
- Inherent team ownership
- The overall value of process and product
What are the basics of the Scrum Events?
Daily Standup
This daily event is focused on getting updates communicated throughout the full team. This is done by each team member providing answers to three specific questions:
- What was completed yesterday?
- What is being worked on today?
- Do you have blockers or issues?
This event provides the opportunity for clarity and open communication across a product team.
Backlog Grooming
Backlog Grooming is dedicated time to focus on ensuring the product backlog is in tip-top shape. During this event key stakeholders (Product Owners, Clients, etc) will collaborate with select members of the product team (Product Strategists, and/or Managers) to refine and prioritize tasks that correlate to your product.
- Backlog grooming can occur as frequently as your product/team requires
- Lots of incoming bugs and frequent shifts in priority? Meet weekly.
- Only need to ensure your backlog of work is aligned with the goals of the product and stakeholders? Meet bi-weekly.
This event is core for reaching alignment between those who are strategically making decisions, and those who are tactically implementing changes.
Sprint Retrospective
This is an important event to prioritize regularly as a team, as it allows for reflection, learning, growth and overall healthy conversations. Each product team does this differently, but the main discussion points should stay the same:
- How did things go well last sprint?
- Were there times last sprint that things weren’t going so well?
- How can the team improve moving forward?
Retrospectives can be done as frequently as your team sees fit. At Crema, we conduct retrospectives at the end of each sprint, so that learnings can be applied quickly.
Sprint Planning
This event is broken up differently, depending on the organization, client, or product. Here at Crema, we like to include Sprint Reviews, Demos, Refinement & Story Pointing during our planning event.
1. Sprint Review
During sprint reviews, the team will discuss any work that was accomplished over the last sprint. Many times, this means walking through each individual ticket, and discussing specifically how/what was accomplished.
- The team may use this time to break apart incomplete tickets, as well as allocating any effort (points) for the incomplete tickets.
- Any new items found during testing can be discussed, and new tickets can be created and prioritized as needed.
2. Product Demos
After the sprint review, the team shifts direction to focus on what is headed down the pipeline. This timeframe is best utilized to allow for demonstrations of design progress.
- Remember: any designs that are shown are always subject to change based off of feedback.
- These demo’s should be fairly short, but if additional (or thorough) feedback is needed, schedule time outside of your sprint planning for followup.
3. Story Refinement
Story Refinement is how our ideas are brought to life. This process is how we determine exactly what is implemented throughout a product lifespan. Story writing takes collaboration from the whole team throughout different stages of the process.
- Stories should be initially defined by the Product Manager/Owner prior to team refinement.
- If any additional context or acceptance criteria is discussed when the stories are brought to the full team for collaboration, the stories should be updated accordingly.
For a deep-dive into User Story writing, be sure to check out our post: How To Write User Stories.
4. Story Pointing
Story pointing provides a product team the tools they need to measure the complexity of a story. By assigning value to individual stories, you can set your team up to better understand their overall capacity and predict what volume of work can be completed in the future.
- Utilize a pointing scale that works best for your team.
- Understand that each team you work with can have different velocity metrics.
5. Sprint Commitment
As a team, you’ll review the selected (and refined) stories and make a commitment for the sprint. When this is done, it’s important to understand that the full-team is committing to completing everything that is in the sprint, including development, testing, and merging changes.
In order to drive understanding in this area, it’s suggested that the team summarizes their commitment into a statement (sprint goal) and confirms alignment of that goal with the client.
For more information on perfecting your Scrum Events, be sure to check out our post → The 4 Scrum Ceremonies Made Simple: A Quick Guide To Scrum Meetings.
What are common challenges with moving to Scrum?
Product design and development isn’t inherently an easy thing to do, which is why so many organizations come to the experts (like Crema!) to do it for them. Each method of implementation (and their corresponding frameworks) have positives and negatives, so it’s important to choose something that’s going to best work for your specific team, client, and product.
Going from Kanban → Scrum
Kanban is another Framework option within Agile development, and it can be an incredible way to produce a product. However, when teams make the transition from Kanban to Scrum, there can be a lot of learning in the process.
Kanban doesn’t typically work in sprints. Which means that when using a Kanban framework, new priorities are easily injected into the current development pipeline. Scrum requires teams to commit to prioritized work and stick to their commitment (as much as possible) rather than allowing for continual changes in development or design focus.
This shift in thinking can be difficult for projects that have frequent changes in prioritization (including production bugs, project focus, client request, etc). These sprint commitments may seem hard, but they’re intentionally used to guide the team towards a focus on prioritization and provide an overall sense of stability.
Going from Waterfall → Scrum
Waterfall is a methodology (just like how Agile is a methodology) that can be used for product/project management. Waterfall has been used far and wide, from large enterprise clients to small businesses and startups. This methodology is the granddaddy of product/project management and has been around for quite some time. When this method is used, members of the product team fully scope all product features and timelines before development or design is started.
When using Agile & Scrum, product scope is done a bit differently. Although upfront planning and thoughtfulness is a key component, Agile & Scrum allow for flexibility in features and in timelines. This distinction can cause a lot of friction when teams are transitioning from Waterfall to Agile and can be a large deterrent from completely moving teams and processes over to Agile.
So, why use Scrum?
When building products, it can be hard to initially predict every possible external and internal factor you may face, even with the most methodical evaluation and plan in place. When utilizing Agile & Scrum, you allow your team and project the ability to adapt to the changing needs of users and stakeholders (while keeping the product goal top of mind). These adaptations (or shifts) are what we call iterations.
Iterations allow your product the ability to become the very best version of itself, as needs and requirements inevitably change over time. These iterations give your team the chance to pose questions/develop solutions for use-cases as they arise, while balancing the needs of stakeholders, clients, and end-users. But most importantly, these iterations give us, as humans, the opportunity to continually and intentionally grow our skills and knowledge, all while building amazing products.
So, is Scrum a little less of a crazy concept now that we’ve clarified some of its components? We sure hope so.
How are you utilizing Scrum in your workplace? Do you have other questions about Scrum? Are you interested in hearing about some of the other “cast iron skillets” of product management? If so, give us a shout in the comments below! We’d love to help (and we love to talk about what we do, too). Cheers!
