How do we work with customers? Scrum Framework in Dema project

Main Goals

GetInData has successfully introduced the Scrum framework in cooperation with Dema. Thanks to the use of Scrum, the results of the cooperation created outstanding services and applications in less time. We also managed to create more new features that can benefit our customers in many different ways.

The Scrum framework helped us to achieve the following goals when building innovative data/AI solutions:

• Deliver meaningful results that brought value to the end users in short-time (the first demo for the client was completed within 2 months)
• Have the long-term vision of the project -  the Product Goal in mind, so that the solution that we built could  be easily expanded upon later if necessary
• Minimize the costs & time needed for refactoring if we discover new requirements or current requirements that need changing 
• Make sure that a small team can start working on a project and have the necessary skills and competencies available in order to deliver it successfully. 

About Dema

Dema creates a platform for delivering actionable insights for e-comms to achieve profitable growth. The platform will change the way companies evaluate their marketing campaigns, customers, inventory, orders and website. The platform helps e-commerce companies to get a good insight into all commercial operations to ensure a profitable growth today, tomorrow and in the long-term future. It allows the user to evaluate actions based on 3 levels of profitability and the Customer Lifetime Value-contribution. In addition it evaluates your marketing based on the true ROAS (Return On Ad Spend), which is not based on revenue, but profit or Customer Lifetime Value. All in real time.

Scrum Definition

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat.

The scrum philosophy, theory and structure helps to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than providing people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Various processes, techniques and methods can be employed within the framework. 

Product Vision

All projects start with a Product Vision. This is a fundamental step for both parties to understand the Product Goals. By definition - Product Vision is just that -  a vision, it’s not yet the step to have full analysis and full backlog decomposition (compared to Waterfall methodologies). Together with the Dema team we successfully accomplished on-site common workshops where the entire brainstorming process took place. Both teams discussed the Product Goals, asked tens of questions, received tens of answers, discussed the technical details and proposed initial plans for the first Sprints of work. The Product Backlog was formulated at this point and the first user stories and tasks showed up in the Product Backlog.

Product Backlog

An essential component of this discussion is the collection of User Stories. Collecting requirements is a hard task to carry out and user stories are great examples of how you can combine non-technical descriptions for technical experts.

In software development and product management, a User Story is an informal, natural language description of the features of a software system. They are written from the perspective of the end user or user of a system, and may be recorded on index cards, Post-it notes or digitally in project management software. Depending on the project, user stories may be written by different stakeholders such as the client, user, manager or development team.

User stories are a type of boundary object. They facilitate sensemaking and communication and may help software teams to document their understanding of the system and its context.

The most common is the template:

As a <role> I can <capability>, so that <receive benefit>

With user stories you give a development team the context and the why of what they’re creating. Doing so helps them understand how they’re providing value for the business and to keep the user/customer top in mind.

Together with creating User Stories we focused on ordering them with the highest priorities on the top, and lower priority on the bottom of the backlog. This way, any tasks associated with the User Story share the priority among other tasks.

An example of an initial Product Backlog with User Stories that includes the information about their importance and priority:

1 weekly Sprints 

A Sprint is a short, time-boxed period that a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software. In Scrum, the product is built in a series of iterations and sprints that break down big, complex projects into smaller sized pieces.

We decided to go with 1 weekly Sprint. Our experience shows that if:

1. A project has a relatively short deadline (3 months from now)
2. A project team has just been created and team members are starting to get to know each other
3. The aim of this project is to keep the high velocity of the work and being open to late changes

then 1 weekly Sprints are the most appropriate approach. At a later stage of the project lifecycle when the product is more mature and the team has gotten to know each other and their competences better, then 2 weekly Sprints can be introduced.

Importance of Scrum Sprints

When Scrum sprints are managed and run successfully, they can be very beneficial and improve project outcomes. Below are some of the top benefits Agile Scrum teams gain from well-run sprints. 

More transparency

At every stage of the Sprint process, the Scrum team collaborates and shares ideas that could impact the project’s success. Team members are free to express any objections, keeping in mind the goals and objectives of the sprint and project at large. This ensures that everyone remains on the same page and reduces the chances of project failure. 

Increased productivity

The Sprint process helps improve the productivity of the team and enables continuous improvement. The main result of a successful sprint process is that the team is able to work on high-value, high-priority tasks and features. 

Improved focus and clarity

Scrum Sprints normally encourage the breakdown of a project into smaller tasks and objectives. This ensures that the team focuses on achieving the  particular Sprint goal at hand. This means the team isn’t focused on a million different tasks and priorities at once. 

Flexibility

Working in sprints enables the Agile Scrum team to adapt and respond to change based on evolving priorities and customer feedback. Agile project management requires a level of team flexibility. Sprints ensure that teams are not overly rigid or planning too far ahead and are able to respond to change.  

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. All attendees are prepared to discuss the most important Product Backlog items and how they compare to the Product Goal. 

Sprint Planning addresses the following topics:

Topic One: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

Topic Two: What can be done during this Sprint?

Through a discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident they will be in their Sprint forecasts.

Topic Three: How will the selected tasks get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

The Sprint Goal, the Product Backlog items selected for the Sprint plus the plan for delivering them are together referred to as the Sprint Backlog.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools and their Definition of Done. Inspected elements often vary within the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

Tasks Estimations in Scrum Framework

Estimation is quite challenging to master but a crucial part of the project. Since it is not an easy task to estimate the workload to complete the tasks, there are numerous techniques that can be used to help with this. One of the techniques that we decided to use in the Dema project is to use T-shirt sizing to specify the complexity of the tasks.

Depending on the size of the task, the developers will assign a T-shirt size. It’s important that all developers arrive at a consensus on the t-shirt size assigned to each task. The stories and tasks are all placed in S, M, L, and XL  buckets and the time taken to complete all the tasks in the buckets is estimated. Teams can obtain a relative understanding of how big or small the story is.

The strengths of the T-Shirt Sizing is that everyone is familiar with shirt sizes, which makes it a great option for new teams that don’t have much shared context from working together.

The T-Shirt technique fits really well for the Agile and Scrum way of working, as it is easy to understand and includes the part of uncertainty that comes along with all the development work. At the same time, the estimations can provide an important insight into the amount of work in the scope in relation to the calendar timeline.

T – shirt sizing to determine project scope

Estimates are great, but they have a very specific purpose - to support decisions regarding planning the Sprints and Product development. To get a good perspective of the amount of work to be done, we decided to use a popular technique which is the Gantt chart. 

An Agile Gantt chart is a bar chart that offers a timeline view of an Agile project. There is a vertical list of tasks on the left-hand side with corresponding start and end dates. These tasks are also visually represented on the right-hand side with horizontal bars. The length of the bars corresponds to the amount of time your task will take. 

Gantt diagrams illustrate project schedules and help visualize the start and end dates of any process. In the context of Agile software development, such charts are used to illustrate releases or sprints.

As visual representations of the progress made against estimates on any activity, process or project, Gantt charts can greatly facilitate communication. Since these diagrams are easily understood by all parties regardless of language or expertise in Agile software development practices, they are useful tools when trying to collaborate with, or report on their progress to several teams and departments across various regions.

Gantt charts can be employed to keep an eye on the logistics of a project. Task dependencies ensure that a new task can only commence once another task is completed. If a task is delayed (it happens to the best of us), then dependent issues are automatically rescheduled. 

Our Gantt chart includes milestones, dependencies and other important metrics to track a project’s progress.

The Gantt chart is constructed using the following items:

• Bars: Agile project tasks are represented by rectangular bars. These bars are often color-coded to differentiate clearly between tasks.
• Dependencies: A dependency is the link between two tasks, where one is dependent on the other. Lines or arrows connect tasks on a Gantt chart, showing which ones need to happen in a certain order.
• Dateline: This is the line on top of the horizontal axis that shows calendar dates.
• Milestones: A milestone is a specific point in an Agile project that is used to measure progress. It is represented by a diamond-shaped icon.

Product Backlog Refinement

In Scrum, Backlog Refinement is an ongoing process in which the Product Owner and the Development Team collaborate to ensure that items on the Product Backlog:

• are understood the same way by all involved (shared understanding),
• have a size estimate for the (relative) complexity and effort of their implementation,
• are ordered according to their priority in terms of business value and effort required.

Backlog Refinement is about creating a shared understanding of what the Product will and won't do, the effort it will take to implement it and the order in which you’ll do this.

A Product Backlog Refinement meeting was held together with the Dema and GetInData teams once a week and usually took around 45 min. This helped to keep the Product Backlog in good shape and ensure information flow around the developers as to what part of the product was highest in priority in a constantly changing environment. 

Backlog refinement is to ensure that the backlog remains populated with items that are relevant, detailed and estimated to the degree appropriate with their priority and in keeping with the current understanding of the project or product and its objectives.

Summary

Using the Scrum framework when building innovative data/AI solutions is beneficial for both sides. This way of working with clients helps us achieve the first results in a short-time period and we can start projects with a small, well designed team with necessary skills. At Dema we delivered the first results in 2 months with a team of 3 people from our side and 5 from the clients team. We enjoy working in Scrum because on the one hand it gives us a long-term vision of the project goal and on the other hand we can minimize the cost and time when the requirements have to change. This is something that our clients need.