DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Advancing to Agile From the Traditional Product Management Approach
  • What Is Agile Methodology?
  • What Is Agile Development? Part 1

Trending

  • Effective Exception Handling in Java and Spring Boot Applications
  • Indexed Views in SQL Server: A Production DBA's Complete Guide
  • Run Scalable Python Workloads With Modal
  • Misunderstanding Agile: Bridging The Gap With A Kaizen Mindset
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. 8 Best Practices to Start a Scrum Project

8 Best Practices to Start a Scrum Project

Want to get onboard the Scrum train? Start right here with a list of best practices to onboard from the start.

By 
Barry Overeem user avatar
Barry Overeem
·
Jul. 15, 16 · Opinion
Likes (3)
Comment
Save
Tweet
Share
15.6K Views

Join the DZone community and get the full member experience.

Join For Free

Currently I’m writing a series of blog posts about the retrospective I facilitated during Scrum Day Europe. I’ll describe the strength of Scrum, experienced frustrations, small improvements and also what should be the focus the upcoming years. For the latter the participants suggested Scrum should focus on creating value-driven organizations. While doing some research on this idea I stumbled upon an old blog post I wrote two years ago: ‘6 Best Practices to Kick Start Your Scrum Team‘. The idea was to copy a small part of this article but I ended up rewriting the entire blog post. The result is what you’re currently reading. After this blog post I’ll continue the series based on the Scrum Day Europe retrospective.

Customer Collaboration over Contract Negotiation

The purpose of Scrum is to create ‘done’, usable, and potentially releasable increments. Increments that deliver value to customers each iteration. Increments that delight the customer.

A truly value-driven organization also embraces value-driven contracts. These are contracts that have a foundation built on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting to new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.

In reality, however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…

The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations, the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product will be the result and the relationship and trust is damaged deeply.

But how to gain trust when you haven’t worked together before?

How to start a new Scrum project and setup a contract that focuses on outcome instead of output?

To answer these questions I’ll share some best practices. Mainly written from my experience working for a web agency as a supplier, completed with fulfilled Prowareness engagements.  This is also the perspective I use. The customer is an external client asking support for a software development project.

8 Best Practices to Start a Scrum Project

1. Create the Product Vision & Product Backlog Together

Often the customer has an idea about the product and it’s possibilities but a Product Backlog is still missing. A good practice is to organize a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally, you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realize his dream. They are the ones he needs to trust.

2. Estimate the Implementation Effort of the Product Backlog Together

After creating the Product Backlog together it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions and questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.

Slide1

3. Determine the Business Value of the Product Backlog Together

When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner.

After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like:

  • PBI D, E, F, and G have a low implementation effort and lots of business value. So start with these items first.
  • PBI H and I will take quite some effort to implement and won’t offer much business value. So do we really want this on the Product Backlog?

Slide2

4. Clarify Dependencies Between Product Backlog Items

When the implementation effort and business value is determined for every Product Backlog Item, it’s time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like:

  • PBI C is a bottleneck. Discuss this item in more detail to solve the dependencies.
  • PBI J and K also have a dependency, so take this into account when ordering the Product Backlog

Slide3

5. Start Small

Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you’ve created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first ‘done’, valuable and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there’s enough mutual trust to start another Sprint.

6. Invite the Customer to the Scrum Events

Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.

7. Sell the Entire Scrum Team

Fixed Scrum Teams that have been working together for a longer period, have experienced ups and downs and know their velocity is worth gold. A common pitfall is to separate this ‘golden team’ when a new project arrives. Don’t do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum Master, developers etc.

8. Sell Sprints

When working with fixed teams that know their velocity, it’s also easier to sell sprints for this team. Of course, velocity is something for the team, will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog and give a range of how much Sprints the realization will probably take, for example: between 5 – 7 Sprints.

Because the team is fixed they also know what the costs per sprint are, for example, 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed the upcoming Sprint. They can discuss how much value the will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.

What’s Your Opinion?

In the end, it’s all about trust. Creating the product vision and Product Backlog together, estimating the Backlog, determining the business value and dependencies, starting small and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there’s a foundation of trust it also becomes easier to sell the entire Scrum Team and sell Sprints with a focus on business value. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.

When the described examples are applied more often within organizations, the possibility of truly becoming a value-driven organization also increases. My hope for the upcoming years is that organizations that use Scrum, also use contracts that respect the Agile mindset and start new Scrum projects with a focus true collaboration.

What are best practices for Agile contracts or starting a new Scrum project that worked for you? Would love to know your point of view!

scrum Sprint (software development) agile Trust (business) Software development

Published at DZone with permission of Barry Overeem, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Advancing to Agile From the Traditional Product Management Approach
  • What Is Agile Methodology?
  • What Is Agile Development? Part 1

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: