How Much Documentation Should a Scrum Team Do?

I get this question invariably asked by almost every team that’s new to Scrum.

“Documentation that is just enough,” is the theoretical answer.

Almost always, the next question follows, “What’s just enough documentation?”

just enough documentation

Just enough documentation is what serves the sprint purpose. Imagine the following scenario:

  • Product: A Mobile iOS App in the Travel Niche
  • Pretext: Version 1.0 of the App is already in the market and people are using it. It has generated a user base of about 15000 and many people have requested  different features via App’s support a feature option.
  • Sprint Goal: Build and release version 1.1 of the already successful App. Version 1.1 should have 3 most demanded features by the end users. Out of 3 features, one feature required R&D and hence Scrum is a better choice.
  • Sprint Duration: 2 weeks
  • Team Size: 5
  • Team Details: ScrumMaster (1), Product Owner (1) and Team members (3). Out of 3 team members, one is Graphic Designer, one is Software Developer and the 3rd one is App Support Executive.

Effective documentation in this case could be as follows:

  1. User Stories for the 3 features
  2. Photoshop PSD file with explanatory layer name and optionally a readme.txt file with bullets of specific instructions if any
  3. Readable, modular, commented code that itself is self-explanatory with occasional in-code comments stating why a complex thing is done the way it is done
  4. Updates in the App Support FAQs / Other Support Docs that are affected by introduction of these features

A Scrum team’s goal is to deliver value, fast. Above might act as just enough documentation for the needs. The good thing about Scrum is a specific ceremony called Sprint Retrospective which becomes instrumental in inspecting and adapting to what turns out as the right thing.

When we talk about documentation, often a question comes about the User Manual.

Let’s consider the same in the above scenario: Given it’s an iOS App, it won’t be a good idea to develop a User Manual for the same – The App’s UX should be so natural to the user that they don’t need to refer to the manual.

It is easy to agree to develop a user manual for an iOS app but in fact, that will be a disservice to the end users and the client itself – as you’re disregarding the manual-less experience that is possible to provide to the end user.

Or even better, provide the functionality built in app that enables the user to learn the App by seeing it in action. The need to documentation turned into a functionality!

Many people will say that if client demands, carry out the documentation. However, I do not buy into the idea that if your client requires XYZ documents to be created, you should carry them out without asking questions that provoke her to think – you should explain your client the value a particular activity will bring or the value that it will negatively impact. Sure, typically it is done by the Product Owner but as team members, if you decide to do something in which you don’t believe, you cannot deliver value.

Spirit of Scrum is not to negotiate but to collaborate – when you collaborate towards ONE goal, no one is superior to the other.

Sure in typical Business situations, you might have to do what might look like “anti-scrum” or not “scrum-friendly” – if you choose to do so, do it with awareness.

3 Tips for Product Owners to Survive the Chicken Test

As a Product Owner, why should you even think about the Chicken Test?

For a simple reason: You are accountable for ensuring that the product you’re working on achieves its goals.

The chicken and pig metaphor suggests that the difference between ham and eggs is this: the hen is involved, but the pig is committed. While Chickens may have other priorities, pigs have only one goal – make the project successful.

When it comes to Scrum, surviving the Chicken Test means that the Product Owner is not treated as someone who is not a member of the team.

Theory says that the Product Owner is a pig, committed to the project and judged on the results. However, the role of Product Owner is the most critical one in terms of conflicting priorities.

In practical world, often the Product Owner role is assumed by someone whose primary job is to directly face customers or interact with other critical stakeholders and in such situations, the scrum team may feel that they are interacting with a Chicken when they are communicating with the Product Owner.

When the Product Owner is treated as someone outside the team, there is a high probability that not the Product Owner’s other responsibilities but his behaviors are making the team uncomfortable.

It is obvious that most people don’t like to be with people who make them uncomfortable. Scrum teams are no different.

Team being uncomfortable with Product Owner is an impediment as it can impact their ability to deliver.

The team will react using more or less predictable behavior. You will be treated like a Chicken. Your inputs won’t be appreciated in daily scrums or retrospectives and the level of comfort will be less amongst the team members when you are around.

The result? Conflict among team members. Demotivated team.  Ineffective sprints. Delayed release cycles…

No Product Owner wants that, do you?

Here are my three Tips for Product Owners to Survive the Chicken Test

1. Honor your agreements:

Product Owners often get situations where they have to obey other commitment at a cost of the commitment they have made to the team.

Particular instances could be as small as promising and not meeting daily scrum or as critical as delegating the huge part of Product Owner’s responsibilities to a team member but the point is – the agreement is dishonored.

Don’t do that. Always honor your agreements.

The team cannot trust a Product Owner who does not keep his promises.

If the team cannot trust the Product Owner, the very essence of Scrum is compromised.

Don’t make agreements that you cannot honor. Period.

2. Exhibit unconditional commitment:

Let us face it. Almost all Product Owners are committed but not unconditionally. At least not always.

They may attend all the Daily Scrums as agreed but may not always pay attention to the junior most team member’s point of view.

Even if the junior most team member is not adding much value at the very moment, she at least deserves all the team members’ attention.

That is very basic but often not practiced as it should. Now, that’s an example of lack of commitment.

So how do you deal with that? Don’t choose to be the Product Owner if you cannot offer unconditional commitment for the project.

You may be an important stakeholder or the core Project Sponsor but you cannot be the Product Owner if you have any other priorities than making the project successful.

Have unconditional commitment if you take the Product Owner Role.

3. Make yourself available:

If you are NOT available when needed, it is often perceived as lack of commitment. When it comes to be part of a team that has ONE goal, managed perceptions are much better than assumed conclusions. None other than Product Owner can own that fact.

For any clarification or insight the team might need, Product Owner has to be available for the team.

There is an another aspect of making yourself available. You make yourself available to the team when you develop a personal rapport with team members such that they don’t hesitate to ask you questions. If team members do not feel closeness, changes are very high that they won’t consider that the product owner is available.

At the end of the day, as a Product Owner, you have to deliver the results. You’re rewarded if you do, you’re fired if you don’t.  If you don’t pass the Chicken Test, you need to work on yourself. If that’s the case, don’t wait, go fix it.

How Every ScrumMaster Should Deal With Attention Issues?

Ever been part of a team where team members didn’t pay attention to what was being communicated?

Yes, in Scrum teams also that happens. Especially in the Daily Stand-ups.

Team members don’t always pay attention to what other team member is saying.

Most people get this habit from their daily lives. They go to doctor and while talking to them, they’re checking their BlackBerry. The same people go to restaurant with their spouse and spend more time with their mobile device than their spouse.

They are just like that. Involved in something else when they’re with someone else.

No wonder that kind of people would want to do the same even when they are part of a scrum team.

That’s not acceptable.

As ScrumMaster, you must coach every team member about importance of attention.

Conversations are most important tools in agile frameworks. They get your work done. And you can’t have a conversation without your team members listening to one another with 100% of their attention.

Listening with intent and with 100% attention is what makes Scrum team successful. That becomes and impediment if not resolved early.

Non-listening frustrates people and they tend to lose interest in the project.

Scrum team members are also human beings with their strengths and weaknesses. Scrum team is a committed team and commitment works when every team member trusts and respects one another.

If that does not happen then Scrum processes might still be there but there won’t be a Scrum team.

As a ScrumMaster, coach your team members to listen. Re-state and coach again and again so that they get why it is important.

Your conversations show who you are. Let your conversations say you’re committed. Let the whole team get it sooner than later. If not, then you’re not doing the right job of a ScrumMaster.

When Scrum Works?

Last week I wrote a post called “When Not To Use Scrum?”

Objective of that post was to highlight some of the situations in which Scrum may not be that effective. Nothing is perfect in this world; Scrum is no exception.

It doesn’t have to be.

Most important thing is to know when Scrum works and when it doesn’t and make the best use of it when it works. As I always say, “Scrum is a vehicle, not a destination.”

So here come some situations that are favorable for making a Scrum implementation successful.

  1. Scrum implementation in your organization has got conscious top-management buy-in.
  2. Top management would like to take the cost of implementing “pull” systems over “push” systems. Such costs may be huge in the beginning.
  3. Hiring process is updated to hire people who are strong team players. If a person is great individual contributor but not a team player, s/he is not the right fit for a Scrum team.
  4. Performance Appraisal systems are updated to evaluate team performance rather than individual performance
  5. Scrum teams are made of people who are level 3+ according to Maslow’s need theory who would inherently love to self-organize.
  6. People have high respect for one another regardless of their different, individual opinions or point of views.
  7. People work on one and only one project at a time.
  8. People “pull” the work, no manager is required to “push” the work and get things done by constant follow up.
  9. People understand the definition of “done” – and they commit to it. If they need external forces (aka “manager”) then it is unlikely to work.
  10. Organization’s value system is based on doing right kind of “less” compared doing generally “more” in all that they do.
  11. People are ready to rise beyond their individual title such as Technical Leader, Business Analyst or Senior Engineer and work as a team member who is driven internally, not by any external thing such as title.
  12. People work at a sustainable pace – they have good work life balance and most important, they value it and consider organization as a valued partner in this.
  13. The person playing the role of “The Product Owner” works on only one project and always owns the priority of the features to be developed.
  14. Everyone involved understands that Scrum is a mind-set not a methodology.

Scrum works when people implementing it make it work. Remember, Scrum never succeeds or fails; people implementing Scrum do.

Beware of Scrum

One of the most common causes I’ve observed in failed Scrum implementations is: Scrum team does not have conscious top management buy-in.

I have seen department heads attending courses of Scrum and opting to implement Scrum in their projects without ensuring top management’s conscious buy-in.

They sometimes do it because they feel Scrum is a smart way to ensure project delivery and probably the silver bullet.

It is not.

It may sound easy though. Power of Scrum rests in its simplicity. But in order for that simplicity to work as a tool to get things done, the top management…key decision makers… have to buy into Scrum.

Scrum requires a  paradigm shift about  how things get done.  Not by push but by pull.  Now, that’s simple  but certainly not easy.

Conventional management is primarily about command and control or carrot and stick as we call it whereas Scrum is about giving away the command and control in the individuals’ hands who will act as a self-organizing team to achieve a common goal .

Top management has to make a conscious choice if they want to apply Scrum framework to execute their projects. They need to look at it from multiple perspectives including the nature of projects the organization will be undertaking.

If the nature of project is predictable and not uncertain, Scrum may not be a good choice. However, if the opposite is true, Scrum can be the most powerful tool a project can ever have given the right team.

As a Scrum team, you need to figure out whether your project has got top management buy-in or not. If not then first thing you can do is to bring that up in your daily stand-up meeting as most crucial impediment to be resolved.

Such impediment removal might result into a project which doesn’t use Scrum but that is the right thing to do.

Extreme Scrum-thinking: Don’t use Scrum if that’s the solution to removing the main impediment.


Is Daily Scrum Overrated?

I’ve observed many new scrum teams claiming that they are doing Scrum very well because they are religiously attending Daily Scrum meeting.

They believe that attending this ritual is the silver bullet. It will solve all the problems they’re having. Not matter what the problems are…unclear requirements, unclean code or inadequate skills of the team members…whatever.

All they know that they need to answer three magic questions and they’ll be able to solve all the problems:

  1. What did I do yesterday?
  2. What I’ll do today?
  3. What are the blockers?

But, does it happen that way? Ever?

I doubt.

Haven’t you ever observed your team saying that there aren’t any blocker issues but fail to deliver as committed? I have.

So, where is the problem, Is Daily Scrum Overrated?

As I see it, Daily Scrum isn’t overrated but the teams following it sometimes believe that just attending Daily Scrum they will succeed. That never happens that way and they think if Daily Scrum is overrated.

A Scrum team has to understand that there are no silver bullets. In fact, three magic questions provide the team a framework to exhibit the team-commitment and bring the nastiest impediment out such that it can be eliminated sooner than later.



To really get benefits from the Daily Scrum, the team has to have the right mindset.

The mindset that makes the Scrum team effective is:

They are the ONE team, not individual piece of excellence.

If Engineer X is having an impediment in coding part, Engineer Y who works on quality assurance part is equally concerned and vice versa.

There are no silos. No team member is successful till every team member is successful.

Each team member is committed for ensuring that every other team member wins. Chief goal is to deliver to sprint commitment, not to the individual commitment.

There is shared ownership and shared celebrations.

Daily Scrum is less about doing “Daily Scrum” ritual and more about ensuring that team delivers as per the commitment. [Tweet this]

When team gets it right, Daily Scrum starts generating immense value.

Why ScrumMasters Should Say “No” to Multiple Projects at a Time?

“The shortest way to do many things is to do only one thing at a time.” ~ Richard Cech

Few days ago, I wrote an article for The article is about the  Seven Things I Wish I’d Known When I Started out as a ScrumMaster.

One of the things I mentioned there was to work on one (and only one) project.

In the article, I explained why it is important for a ScrumMaster to work on one project at a time. The explanation was simple: Working on one project at a time brings-in required focus to do your best.

I got many comments there. Out of them one of the comment was about the above point. The commentator mentioned that if the organization has gained required maturity about Agile and Scrum, then they can use a ScrumMaster to do “more” jobs.

I had to respectfully disagree.


Being an effective ScrumMaster is a full-time job. Period.

Unfortunately many organizations that do not have right understanding of Scrum sometimes fail to recognize that a great ScrumMaster has NOT to work on multiple projects at a time.

For example, consider if a ScrumMaster is working on two projects and in order to resolve an impediment in one project, he has to spend several days.

Obviously the other project will have to suffer. At his best, the ScrumMaster will be able to devote 50% of his time to each project, isn’t it?

Also, when impediments are not resolved in timely manner, it frustrates the team members and produces not-so-positive outcomes.

I have seen that organizations that get maximum benefits of Scrum prefer that a ScrumMaster is working on one project.

Then the commentator called me to ask: “Is it a rule in Scrum that a ScrumMaster cannot work on two or more projects?”

No, it’s not a rule. It’s about choosing the right thing to do. Sure, a ScrumMaster can work on multiple projects but most probably with mediocre results. That’s why effective ones do the opposite.

And, the greatest gift an organization can give to a Scrum Team is the gift of an Undivided ScrumMaster.