Scrum is an easy process to understand but not as easy to do well. It has many facets which if overlooked, results in failure of scrum team and erosion of the agile process. Scrum, done correctly, leads to creating a “YaY” team that is small and focused to velocity and an environment that is cooperative with the fire and willingness to succeed. But it requires a good understanding of how those facets affect the scrum team and sprint. Rather than discussing the scrum process, I would like to focus on the parameters that makes a YAY Scrum team.

The Team Dynamics

Team is formed of various shapes and size. Skills, work style and experiences varies extensively combined with behavioral variations as well. Some developers like collaborating while some like to work alone. Some like to dive in and some like to investigate and prepare before diving in.
As simple as it sounds, it is still a complex variable of sprint and iterations. The first and foremost important step towards a successful scrum team is to understand the team mix itself. The team size, expertise, specialization and ownership is very important before planning any sprint.

What really matters …. Is how the team is organized around the feature or product? Do they have everything in place to be able to deliver a working tested increment of the software? Do they fully understand the user stories? Can they understand the business value of it? Can they estimate it? Do they fully understand the backlog? Do they have necessary resources to commit?

The team is basically an accountability structure from top to bottom. If the structure does not have everything required, then they cannot be held accountable. When a team doesn’t have everything necessary to be successful, it erodes the sense of urgency around getting things done. Velocity destabilizes and no one cares. No one is accountable for making progress on the product and the team becomes a victim.

The bottom line is that if you cannot create the right mix of scrum team, you are en route to dead-end filled with some nasty surprises. Better find out some other innovative way of developing software than following agile and scrum. It’s that important.

The Project Increment

Like the team, the project also comes in various shapes and sizes. It sounds simple, but when observed carefully and in-depth, a project requires many things to be done before it is demoed to the end user. Planning, Research, Designing, Coding, Reviewing, Testing, Staging, Deploying, Documenting and many other stuffs. All parts of the deliverables should be broken down in ready stories.

The team decides what increment they can produce in the sprint and final deliverables of a sprint should not have any technical debt, pending feedback, pending testing, pending UAT or pending documentation. Anything deferred adds indeterminate amount of work at the backside of the project. What matters at the end is that the team have a measurable chunk of the sprint that can be neatly measured as ratios and timelines.


The essence of successful sprint and deliverables starts from backlog. A poorly formed backlog is almost every time the root cause of almost every problem in a failing sprints. A poorly articulated backlog is an outcome of poor sprint planning meetings. If the backlog isn’t clear, the team comes to sprint planning meeting and spends all the time on “what” needs to be done and not enough time on “how” it can be done. It is visible when the team is trying poker, planning and prioritizing on “what” rather than “how”.
Having backlog, that is well captured, well defined, broken into small chunks of tasks and easy for a team to understand and estimate, increases the success chance of the sprint by many folds. The team feels greater control over the tasks. It also help the product owners to determine what value addition can be committed for the next sprint release.


Because the team and the project both varies a lot in shape and size, a concept of ownership of user stories plays a very innovative and critical role. The owners are the subject matter experts and seniors who bring in more experience and quality break down of the story to backlogs. The owners of user stories bring in more holistic view, accuracy, competency and urgency to the sprint. The estimations are also radical and knowledge based. Asking a database administrator to own a QA user story or test plan and try breaking it into tasks is like bringing in grandmother to estimate a rocket engine.
Besides, the owners also brings in a sense of commitment and achievement that is greatly infused with a sense of ownership. The smaller the team wearing many hats, the better the ownership works. However, the owners should be capable and expert of those fields.

User Stories

User stories are the crux of backlog and increments in a sprint. These are the building blocks of the successful sprint. Something, I came across is very interesting concept: “Bill Wake’s INVEST criteria”, which relates user stories to independent investment decisions. Where each letter in the word INVEST is defined as:

I – Independent – The user stories must be independent of each other and self-contained.
N – Negotiable – User stories, up until they are part of an iteration, can always be changed and rewritten.
V – Valuable – A user story must deliver some value to end user.
E – Estimate-able – One must be able to estimate the size of user story
S – Small – A big user story is simply impossible to plan or visualize.
T – Testable – A good user story must have a clear test plan with simple use cases.

A typical format of a user story is “As a (role) I want (do something) so that (business value)”

As simple as it looks it can still be invaluable, excessive or odyssey, when misunderstood and misinterpreted. This always leads the team to sidetrack and get nothing accomplished. Here are some examples of user stories.

Good: As an admin I want to deactivate another user’s account, so that they can no longer log in.

This user story clearly describes role, what needs to be done and business value. It is self-contained, easy to understand, estimate and test. In short it follows all the INVEST aspects.

Invaluable: Send notifications when a contact is created.

The drawback is that it does not state who or what is sending notification. It does not state in what form the notification is sent e.g. email, twitter, SMS or something else. The description does not include any business value information. It is hard to estimate and a tester in the team won’t be able to describe what needs to be tested here. Asking the team to play Poker on it and estimate is like asking a five years old to describe the molecular structure of a rocket fuel.

Excessive: As a salesman, I want to save my customers list, so that I can create a copy, email and print later on.

The drawback here is that the user story is not clear whether saving the list is what’s required or print, copy and email features is what’s needed. There is excessive information in this user story and that leads to misunderstanding and sidetracking. This requires rework in breaking it down or reframing to a more well-defined user stories.

Odyssey: As John the customer, I want to register for an event, so that I can secure my place.

There is nothing wrong in having an epic or odyssey user stories as long as one understands that it must be broken down to ready stories that are self-contained and based on INVEST criteria.

Each user stories in the backlog and sprint increment must meet this INVEST criteria for the team to be able to commit to the working tested increment of the software. The success of a sprint depends on how well these user stories meet the INVEST criteria. Poker, Burndown charts, Retrospection, Sprint planning and all other exercises around sprint is futile otherwise.

Process Overlaps

Many companies who call themselves Agile are not really agile. They still haven’t come off the waterfall model, which ensures more control and tight iterations over sprints. There is a big difference between Agile and Waterfall. Mixing waterfall and agile is too confusing and too uncomfortable. Trying to control over Cooperation becomes a major challenge. Architecture and Design documents getting ready before a single task happens to build the product is simply not agile. It makes the process too complicated and rigid. This doesn't work on scrum. If you are using scrum, your project needs to adhere to the agile mindset. Ownership, communication, co-operation, repeated discussions and elaboration is the key to success. This helps in creating the “YAY” team effect.

Some even try to introduce Kanban outside the scrum process. This creates a distraction and cuts off the modules and member from the rest of the team. A bad practice that develops a feeling of job and duty than achievement and urgencies.

Culture & Shared Understanding

Just following scrum and its top 10 tips does not mean that the scrum will succeed. There has to be a shared understanding. It has to be organization wide. The sprint commitment and risks factors should be well understood by all team members. The culture of the company also plays an important role in how team works. In many cases it’s mostly the culture of control and fear that leads to a non YAY team effect. A non YAY team is like a pieces of robots taking orders.

There is a big gap in knowing scrum and practicing it correct. Without a correct agile mindset it always meets a tussle between waterfall and agile ways. Many keep struggling and sometimes give up scrum process or land up into mix of processes which is too uncomfortable, and leads to no difference than the same old traditional ways. It’s an old saying that people do smart things when they genuinely “want” to do it. A good culture is to fill that gap and inspire people to do things without being gripped by any fear.

Sprint Planning Dynamics

Another effect that works against a good scrum team is influencing planning phase to squeeze time and pressurizing the members to commit to the time squeeze. It should be owner of the user story (not to confuse with product owner) and team to estimate, work and retrospect to improve on next sprint. It must be the part of retrospection on how much each member deviated and how can it be improved. Burn down charts and estimation should be a continuous process. It must be done by the team for the team within the sprint iteration.

Influencing the team during iteration, changing priorities in any way is like taking the commitment part away from team to one’s own shoulder. The basic principle of the Agile and Scrum is to let team plan, commit, deliver and retrospect. Any kind of influence that lets team change the commitments at the beginning or in the middle of the iteration, would result in team always looking for directions and never valuing those commitments.


Even in real life one needs to get a feeling of value addition made to the task or team he or she has contributed to. If not so, one quickly gets bored and tries to escape from it as much possible. It is important for the leads and product owner to feed on the motivation and removing any fear or shy factor from the team member. It is very essential for a team to succeed collectively on what they committed to or commit and see it to completion. By seeing it to completion means, a reward or appreciation of job well done puts the team into high motivation zone.

You need to have a “YAY team” effect before you can see the velocity being met or even better, team beating old records and showing the signs of urgencies. Small wins and achievements works towards strengthening the shared understanding bonds and an environment that resembles a truly successful scrum team gaining on velocity, loosing on debts and beating their own past records.

As always seen, the only way to get something awesome done by a team is when there is a genuine willingness to do something. Thus having a motivated and inspired team is very essential for a successful scrum team – YAY Team!

Signs of failing Scrum Team

  • In sprint planning, team discussing “what” and not “how” they would complete the sprint.
  • User stories does not follow Bill Wakes INVEST criteria.
  • Poker and complexity numbers are arbitrary.
  • You’re having hard time having full attendance on stand-ups or it is forced.
  • Adding additional processes in trying to make the sprint successful.
  • Team being victimized as incapable or dumb.
  • Software failing after being Tested.


Every aspect described here are interrelated. They all must be explored and worked on to create a YAY team effect. If you have most of these right, you are struggling but en route. If not most likely you are trying to control the sprints with multiple processes and still have no clue why it’s failing. You are slipping into waterfall model whereby you are calling it agile. Your team is simply being victimized and coined as incapable to deliver.