SCRUM in a nutshell

Meeting Discussion Ideas Communication Corporate Concept
Picture of Attrecto Team

Attrecto Team

SCRUM in a nutshell

The “manifesto” for agile software development starts with a curious sentiment: 

“Individuals and interactions over processes and tools” 

It’s not that there isn’t value in the stuff on the right, continues the manifesto. It’s that the stuff on the left is even more valuable. 

Scrum, agile and sprints are more than just development buzzwords — they’re ways of working and approaching complex problems that put values like communication, knowledge-sharing, embracing failure, introspection and observation front and center. 

Besides the fact that working with Scrum has brought our software projects major results, there is also something very human about the methodology. 

So instead of having you wade through a number of complex and jargon-heavy white papers, we thought we’d give you the TL;DR version that still answers questions like “What is Agile project management?” and “How can our team begin to use Scrum for software development?”

Source: Unsplash

Scrum in Software

Agile methodology gets a lot of fancy press but there are a number of other similar methodologies, including: 

  • eXtreme Programming
  • Crystal Clear
  • Agile Unified Process 

Scrum’s rise to the top, however, is because of its simplicity, straightforwardness and the ease with which teams, across functions, can implement and collaborate. Often, team members experience perks like: 

  • Feedback gathered from stakeholders, customers and end users throughout the process of development
  • Rapid and aligned reactions to changing requirements
  • The dev team’s increased velocity, thanks to 1-4 week sprints, which provide a sense of urgency and focus
  • Shippable increments delivered early and often, enabling stakeholders to provide real-time feedback (and team members to observe customers in action)
  • Productive, effective, and efficient meetings to help ensure that developers get help when they need it

Scrum is not a process, technique, or definitive method. 

It is a framework that offers freedom of implementation. 

Through organized yet creative “sprints”, Development Teams bring a design thinking and problem-solving mindset to software. User experience is not in the rearview but right in front of you so the team can bring real customer value, which translates to real business value. 

Scrum’s power and potential, then, is all in adopting a user-centered development mindset. This is what can help web development companies create and deliver complex but successful products users can actually benefit from. 

Source: Unsplash

The basic framework consists of Scrum Teams and their associated roles, events, artifacts, and rules, detailed by Ken Schwaber and Jeff Sutherland, who developed Scrum. 

Yet, there are now quite a few successful “Scrum”mers (like Kai Haley, leader of the design sprint training program at Google) and “Sprint”ers (like Jake Knapp, design partner at Google Ventures) who have perfected the art of running a successful Sprint and the formation and facilitation of a Scrum Team to a tee. 

To get started, you’ll need to have an understanding of its structure and working style. 

The Scrum Team

The Scrum Team is made of a couple of concrete roles, which we’ll look at here. Teams are self-organizing and cross-functional.

The Product Owner: responsible for maximizing the value of the product resulting from the work of the Development Team.

The Development Team:team members who work on delivering a potentially releasable Increment of the “Done” product at the end of each Sprint. Development Teams are structured and empowered by the organization to organize and manage their own work.

The SCRUM Master: responsible for promoting and supporting while also connecting with those outside the Scrum Team, helping them to understand which of their interactions with the Scrum Team are helpful and which aren’t.

Source: Unsplash

Scrum Events

Pre-determined Scrum “events” are a great way to create regularity and minimize the need for meetings. Events have a set time duration they can’t go beyond. 

The Sprint

The heart of Scrum is a Sprint, which usually runs anywhere from 1-4 weeks. The goal is a useable, and potentially releasable product Increment. Sprints have consistent durations throughout a development effort. Don’t be surprised if you’re facing 8-hour days of consistent focus. 

Another principle is that a new Sprint starts immediately after the previous one wraps up. 

Sprints consist of the following activities: 

  • Sprint Planning
  • Daily Scrums
  • the development work 
  • the Sprint Review
  • the Sprint Retrospective

While no changes are made that might take the “Sprint Goal” off-course, the scope can be clarified and re-negotiated with the Product Owner and Development Team as more is learned.

Source: Unsplash

Sprint Planning

There’s no need for your team to do much homework prior to the Sprint. But, the designated Sprint Planning stage is where the team creates a plan for the collaborative work to come. It’s also considered an event so, naturally, it has a time limit: a maximum of eight hours for a one-month Sprint.

Daily Scrum

Every day of the Sprint, there is a 15-minute event called the “Daily Scrum”. There is where the Development Team plans work for the next 24 hours and inspects the work done yesterday. The Daily Scrum is held at the same time and place each day to reduce complexity.

Sprint Review and Retrospective

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It is informal and lasts, at most, for four hours. 

The Retrospective is a chance for the Scrum Team to inspect itself and create a plan for improvements for the next Sprint. The atmosphere is open to feedback and sharing because presentation of the Increment is all about getting feedback and fostering collaboration. 

Source: Unsplash

Scrum Artifacts

So Scrum Teams engage in Scrum Events. And Scrum Events inevitably result in Scrum Artifacts. Think of these as the “residue” of activities and events that also give the team opportunities for inspection and adaptation.

  • Product Backlog:an ordered list of everything that is known to be needed in the product. Any requirements for any changes to the product go here. It’s the domain of the Product Owner to advise on/tend to content, availability, and ordering.
  • Sprint Backlog: from the list of “Product Backlog”, the “Sprint Backlog” items are those that are selected for the Sprint; this includes a plan for delivering the product Increment and realizing the Sprint Goal. 

While some software teams decide to cleave design and development into two separate sprints,  others favor an integrated sprint approach that brings together UX designers, developers and testers working together as a scrum team.

The benefit to this integrated environment, especially using Scrum, is that it allows you to constantly maintain a UX mindset and focus. You’re actively testing the product in iterations as you go along, allowing the next increment to thoughtfully reflect improvements from the previous version.


Source: Unsplash

Of course, this calls for a well-functioning development team in order to build a powerful and ingenious product.

However, Scrum comes with a caveat: using it is not a guarantee that you’ll end up with a successful product. 

Agile development companies must embrace the idea and reality of “failure” and ask themselves what this term means to them. 

The other consideration is the role of a UX designer within an integrated Scrum team. It’s the UX designer who keeps a finger on the pulse of the project’s alignment with the customer, constantly bringing a clear understanding of product vision and its requirements. 

This UX focus, then, directly translates into a superior customer experience. 

So, at its core, Scrum ultimately provides a better CX for clients and internal teams. Customers are integral to the framework and need to be deeply involved in the development process. 

It’s the interactions with the customer and their observed experience that help to guide each successive iteration stages. It’s direct involvement coupled with ongoing, incremental working that makes the Scrum framework so powerful in software development.

Download your free guide for development process in UX driven projects

Share this post

The truth about the accuracy of software estimations

Programmers working on computer program
Picture of Attrecto Team

Attrecto Team

The truth about the accuracy of software estimations

Have you ever heard of a “Standish Chaos Report”? Trust software developers to come up with fantastic terms for an otherwise prescient trend occurring in development projects: the incidence of project failures and the factors that contribute to them.
The failure records of software projects in the United States alone is quite staggering. According to the Chaos Report

  • 31.1% of projects will be cancelled before they ever get completed
  • On average, across small, medium and large enterprises, over half of projects will cost 189% of their original estimates
  • While companies in the U.S. spend more than $250 billion each year on IT application development, spanned across approximately 175,000 projects, only 29% of these are ever counted as “successful
  • Meanwhile, Tricentis estimates that software failures cost the U.S. economy up to $1.7 trillion in financial lossesSource: Chaos Report 2017

The truth is that poor estimation can lead to a score of issues, besides simply a time or cost overrun.
It can lead to changing requirements, poor testing practices, software vulnerabilities, glitches, bugs and overall “challenged” projects doomed to reproduce technical failures if launched merely to meet cost and time budgets but not quality standards.

Source: Software Fail Watch — 5th Edition

In a survey of the negative effects and the “erosion” of value on a brand, Tricentis found that, in 2017, consumer tech companies were most vulnerable, with software challenges spanning everything from cost overruns, failures and recurring bugs.

So why aren’t estimations more aligned with the project’s development and parameters?

If failures are occurring consistently, costing companies more than just money — crossing the boundaries into brand equity and power territory — then why can’t we aim to use better estimation methods on projects?

The Cone of Shame

Dog-owners will know how much their furry friends resent the cone of shame.

Software development and estimations are not too fond of the cone either. In our case, it’s the Cone of Uncertainty that hangs, like a dark specter, looming above the commencement of every single project.

Where there should be enthusiasm and anticipation, there is dread. Even though we’re eager to roll up our sleeves and learn from our “past mistakes,” there’s still an edge of uncertainty when we recast our estimations for projects.

In almost 30 years of software development project studies, expert research has concluded that initial estimates on a project can vary as much as four times more or less because neither the estimating team nor the client can yet fully define the scope of the project right at the outset.

In the “waterfall” method (which is the classic approach to development), the Cone of Uncertainty tracks the variance in these estimate-versus-reality scenarios.

As time progresses, a greater amount of the project reveals itself and the scope narrows — which then trickles down to a tighter estimate and a reduction in uncertainty.

Source: Envoc Glossary

But — you knew there was a “but” coming, right? — can we reduce uncertainty to a greater extent and even earlier in the process? Notice that a “reduction” doesn’t have to be an elimination in order to make the project successful.

There are three specific aspects of software development that the brooding Cone of Uncertainty affects:

Consistently “good” products — Maintaining a product or project’s quality requires a particular standard to be set and achieved in a short period of time. Software projects usually have changing features, according to customer needs, and this calls on either a greater level of agility (towards deployment) or more certainty, earlier on in the project’s development.

The requirements of “custom” built software The Cone of Uncertainty undercuts the amount of foresight and planning that custom software development requires. The latter is more about engineering, where even the foundational building blocks must be custom-built. Integrating these building blocks then initiates multiple possibilities and logical paths to be covered so teams will need to constantly refine these concepts.

The ongoing nature of development  —As the Cone of Uncertainty progresses over time, the variance in estimation versus reality reduces. But using the waterfall method also significantly bloats the time that teams spend in the phases of “What are we building?”, “How does it work?” and “What will it look like?”

So we know what those failures look like — but what about success?

In its survey of IT executive managers, the Standish Group’s “Chaos Report” found that, besides user involvement and executive management support, a “clear statement of requirements” (i.e. scope maturity), tied into proper planning can yield overall consistently successful project results.

Source: Chaos Report 2017

The Cone of Uncertainty, however, seems to make even these success criteria seem less than certain.

How can we hope to have more accurate estimations in an ever-changing environment?

Because the consequence is not only a possible failure or a particularly tricky bug that could, as in the case of Provident Financial, a U.K.-based sub-prime loan company, result in a £1.7 billion loss, the largest one-day share price plummet and a CEO resigning over the fiasco.

Factors Affecting Estimations
Now that we know what failure looks like (and, worse yet, feels like), let’s take a look at the factors that affect the estimations on a project.

Massaging the scope into proper maturity

Scope maturity is tied into estimations on software projects. During the planning phase, the development team will need to finalize requirements and think through the requirements from a few different angles.

But the Cone of Uncertainty almost guarantees that designing and anticipating everything up front is almost an impossibility — especially with proper depth.

So what is the solution?

Favoring the incremental approach helps smooth out the development process, making it much more responsive, shortening the initial phases of variance within the Cone of Uncertainty. That’s because the “responsibility” of accurate estimations is spread over the whole development.

In our own experience with developing a web app that models a Digital Transformation Company’s internal processes, we had two parallel goals: to lay down the foundations of a long-term project and to deliver features within hard deadlines.

The custom solution needed to be the only app/tool the business used for internal researching, analyzing and planning. So we allowed the scope to evolve to maturity along the way, using our automated deploy-and-build process.

This bias for agile development is also what enabled our QA team to provide the best quality code for the client.

Concept elaboration
Estimation accuracy relies on more than just scope maturity — it also calls on the elaboration of the concept.

With custom-designed software projects, there is an opportunity, as with digital transformation projects, to use the principles of continuous and iterative building and deploying in order to mature the project in a way that costs less time and cost up front.

But this also calls on developers to have a firm grasp on the concept or specification up front.

This is one factor in estimations that provides more control than others. Teams will no doubt have to perform sprints and rely on breakout sessions to really get to the heart of the concept.

The details uncovered therein for the requirements on a project — such as problem, solutions, features, technical requirements, marketing requirements, etc. — can help anticipate a more aligned budget.

The point is to get as detailed as possible because details uncovered after tells the development team that an estimation was based on basis of flawed assumptions.

Change requests

You may have noticed by now that time is the wily variable that can bog down or uplift a project. Certainly, development teams are always racing against time to capture the right scope and concept.

It’s a reality our team has come across in our over eight years of development and one that especially pitted us against time during a project for Mitt Telenor’s official iOS and Android app.

If the product is set to launch at a specific date, we need to keep CRs at bay and be transparent with the client about how their ever-changing concept puts their project at risk of running well beyond the estimated project numbers.

CRs may well be warranted — but if they’re not anticipated, as agile SCRUM methodology allowed us to do with Mitt Telenor, the project can quickly become “challenged.”.

Source: Chaos Report 2017

Change requests and re-writing code are tasks that fare best in shorter, more responsive sprints.

In the case of Mitt Telenor, these short sprints are exactly what allowed us to uncover issues at an earlier (and more critical) point in development. This then allowed us to keep the development lights on, so to speak, continuing in a more self-aware (or, rather “software-aware”) manner.

The Place of Estimations in the Agile Methodology
To handle these changes and deliver a successful project, both parties (Client & Developer team) are better off with an agile methodology.

Agile allows us to be incremental, responding to a change in business as well as project needs in a more natural way. It’s also easier and more realistic to estimate and then implement changes in small increments, at closer intervals.

Software development is all about change, by its very nature. It is not now, nor has it ever been, a static undertaking. This is why development cannot employ a templated approach, especially in the landscape of digital transformation.

Source: Envoc Glossary

Notice how the Cone of Uncertainty here is significantly leaned out, from its original bloated physique. The result of a consistent diet and exercise? Not in this case. This is the benefit agile methodology brings to the table.

You’ll notice that we’re not claiming that we can simply eliminate or mitigate the Cone of

Uncertainty — no. To do that, we might as well not embark on a development journey at all.

What agile does allow us to do, however, is to drastically reduce the time spent at the initial stages, those questions of:

  • “What are we building?”,
  • “How does it work?” and,
  • “What will it look like?”

And the rest of our time? Well, instead of hemming and hawing, thinking and scratching our heads, only to come up with shaky estimations that are flawed at best and wrong at worst, we can spend our time in our zone of genius: Development.

Indeed, the “development” zone is where our initial estimates are proven or adjusted, requiring less upfront and overall time, and with greater accuracy.

A more aligned estimate and a smoother planning process.

That’s the advantage of agile

Download your free guide for development process in UX driven projects

Share this post