Start out with the Scrum Agile development methodology and get fancy later on. Whether you are an Agile maven or are new to it, wondering which methodology to opt for, you will definitely find our article quite enlightening.

Gone are the times of traditional methods of software development. These days the Agile methodology is an ultimate trend among development teams. Nevertheless, the overwhelming majority of businesses are prone to misunderstand the essence of it and end up associating it with a complete lack of planning.

Plans are of little importance, but planning is essential. Winston Churchill

Agile is an umbrella term that encompasses several methodologies: Scrum, Kanban, Crystal, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD). This time, however, we aim to expand on the value of documentation in Scrum, one of the most popular frameworks for implementing Agile. To get more insight into the Agile methodology, learn why documentation is an asset in Agile.

Let’s do some brainstorming. The Scrum Agile development methodology: what is the first that comes to your mind? Many would say:

laidback attitude;

                                    no documentation;

                                                                         spontaneous change in requirements;

                                                                                                                                                 lack of a clear roadmap;

Well, if you nodded ‘Yes’, in agreement with all the above-mentioned ideas, you got it completely wrong. Don’t jump to conclusions. Let’s figure out together whether Scrum is really used in such a care-free way. Back in 1950, W. Edwards Deming introduced his famous PDCA method, which stands for Plan-Do-Check-Act. As simple as it is, but, indeed, it aptly characterizes the basiсs of the Scrum Agile development methodology. This iterative cycle can be applied to the production of almost everything: cars, video games or even paper planes, let alone IT projects.

Have you read a Jeff Sutherland’s book “Scrum: The Art of Doing Twice the Work in Half the Time”? If not, add it to your list of must-reads. Jeff Sutherland as one of the co-creators of Scrum sheds new light on the topic. He claims that Scrum one managef universal strategy that works perfectly for everything: starting with managing your washing machine, student teaching, and ending with wedding planning. Watch a video below of Jeff Sutherland explaining how to be agile, not just in software development but in every business.



The Scrum Agile development methodology is a completely new approach to managing development teams, taking into account how they really work and not how they imagine their work to be done. To illustrate benefit of Scrum, Jeff Sutherland provides the example of the FBI’s program SENTINEL, the release of which in general took nearly seven years and about half a million dollars. So much wasted money, so many years went down the drain…. The implementation of the Sentinel project according to the Scrum Agile development methodology, however, took only the last year and a half! Staggering difference, isn’t it? But I guess every company at a certai

All drama aside, let us consider the obstacles that impede progress of development teams.

  • Rigorous planning

Many businesses tend to expend too much effort on planning a project instead of doing it. Eventually, everything resolves into mess, because the way people work has nothing to do with idealistic plans.

  • Voluminous documentation

Scrutinised planning results in extensive documentation, namely endless requirements,  diagrams, and schedules. It begs the question: how does one  manage this documentation without getting lost in it? Scrum suggests having minimal documentation in order just to keep track of your workflow.

  • No deviations are possible

Rigid plans impose limits on people. They feel under pressure and are not inclined to think creatively and work efficiently. Uncertainty and creativity, on the contrary, are very welcomed in the Scrum Agile development methodology. It is absolutely ok if at the beginning of a project you are a bit doubtful and hesitant.

  • Optimistic scenarios that are never realized

Projects are usually delayed and over budget due to mismanagement. Optimistic scenarios don’t work in practice. On the other hand, Scrum gives people freedom and encourages self-management. Teams should assess their potential and be directed towards the results. The principal aim of Scrum is to boost the team’s productivity and eliminate obstacles.

  • Lack of testing and revision of the work that is done

What is more important is that companies are not used to evaluating and testing their products. It’s essential in order to improve the workflow of teams and adjust it to the requirements and needs of the target audience. Scrum, however, underlines the necessity of self-analysis and self-assessment.

Scrum is like your mother-in-law, it points out ALL your faults. Ken Schwaber

We have outlined all of these problems for you to be aware of the weak points of IT development teams. It’s true the Scrum Agile development methodology tackles all the problems that exist in traditional methodologies. In this article, we are going to concentrate more on the issue of documentation. So let’s try to clear up the Scrum approach for documentation.

How Much and When to Write It?

As long as there are multiple roles in the Scrum Agile development methodology, each member is in charge of a particular piece of documentation.

Product owner, whose task is to set initial priorities and  product requirements, is a project’s key stakeholder. He is required to take care of the product backlog that is to be periodically refined to ensure the most valuable items are at the top and the less valuable items are near the bottom. Here we have enumerated types of documents through which software requirements specification (SRS) can be communicated:

  • User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.
  • Use case is a list of steps, typically defining interactions between a role (known as an ‘actor’) and a system, to achieve a goal. The actor can be a human or an external system. Use case might be represented in two major forms: use case diagram or structural textual description. Diagrams are, for sure, more vivid and appealing.

By and large, there are five features of good requirements:

  • Necessary
  • Complete
  • Consistent
  • Unambiguous
  • Verifiable

Aren’t you tired yet?

Let’s do an activity in order to check whether you are following my ideas. So what’s wrong with the following requirement specification?

Have you grasped the mistakes? First of all, the question arises whether cars should follow this rule always or only when they see a child or when a school works.  Besides, it is not clear what is meant here by the word ‘present’. On a sidewalk, behind a fence, or in the school yard? It’s a pity, but the majority of businesses’ failures are accounted for by inaccurate and unspecific requirement specifications.

A Scrum team that typically consists of five to nine members organized by a Scrum master who serves the role of a facilitator and liaison between the product owner and team is expected to maintain minimum documentation. Below is an overview of the types of documentation that a Scrum project requires:

  • Sprint backlog

It contains the list of tasks that need to be completed for a particular sprint. Each Scrum member chooses a task and defines time needed to accomplish it. It is important that tasks are short and not assigned, but rather chosen individually. Tasks can be of the following types: design tasks, coding tasks, testing tasks, documentation tasks, etc. They can be divided into several categories: ‘In planning’, ‘In progress’, and ‘Done’.

  • Daily Scrum stand-up

Well, it is not actually a piece of documentation in the true sense of a word. Each day, a team member is to answer the following questions: What did I accomplish since the last stand up? What I will accomplish by the next stand up? What is blocking my progress? It can be done either orally or in a written form. Such a method helps to keep the team in sync, making sure that the process moves in the right direction.

  • Burndown charts

The burndown charts reflect how quickly your team are burning through your customer’s user stories.CLICK TO TWEETGenerally, there are sprint and product burndown charts. The sprint burndown chart makes the work of the Team visible. It is a graphic representation that shows the rate at which work is completed and how much work remains to be done. The product burndown chart show monthly sprint progress. It is a so-called big picture of a project’s progress.

  • Sprint retrospective backlog

A Scrum master is responsible for conducting a sprint retrospective meeting. It occurs after the sprint review and prior to the next sprint planning. The team and the Scrum master meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting. The sprint retrospective should be time-boxed to three hours.

  • Team working norms

These are guidelines developed by the team in order to function smoothly. They should be written down for everyone to have access to them. Team working norms describe internal processes and rules that a team agrees upon and that ensure transparency.

Benefits of writing the documentation in the Scrum way


  • Reduced workload

Everyone contributes to the documentation effort for each sprint. However, there should be a tech writer who can organize the process of documentation creation and manage document version control. It is even better when a tech writer has an engineering background and can get the key points without requiring someone to explain in detail what is going on.

  • Faster process of documentation creation

Due to the fact that in Scrum we document only essential processes and do it on a regularly basis, a project is deprived of voluminous documentation. It is no longer a burden for a team, but rather an essential part of their job which they can quickly get accustomed to.

  • Bug-free code

Getting technical writers involved early is a great way to get feedback on your work.

If your team of technical writers can’t figure out a feature, your customers probably won’t either.CLICK TO TWEET

Having technical writers involved during the sprint can also help testers discover problems and prevent a product or service from getting negative reviews.

Common pitfalls the Scrum Agile development methodology

  • Problem-solving in the daily Scrum

During the daily Scrum stand-up it is not accepted to discuss neither work-related problems nor personal issues. Daily Scrums should essentially be time-boxed to 5 minutes and be limited to answering the three simple questions, and that’s it. At the beginning of applying Scrum to a project, many teams tend to misunderstand the essence of this activity.

  • Frequently reconstituting the Scrum team

Practically speaking, shifting members frequently not only reduces efficiency and productivity but also demotivates team members. In fact, it is a tedious task to form a close-knit team.

  • Excessive up-front planning

There is no point in wasting time on deciding the product backlog much in advance as the feedback gathered during sprint reviews are more important and may completely change the plan.

  • Focusing on tools

People are more important than processes and tools. Finding a great tool is just a small obstacle to getting started, so the teams should start with the development right away.

Results of Implementing Scrum in Our Projects

We started applying Scrum not so long ago but are already reaping the rewards. It works perfectly for us, and we want to share our hands-on experience with you.

You betcha, the Scrum Agile development methodology is a key to a project’s success.CLICK TO TWEET

In order to manage our documentation without going insane, we use Confluence which stores our company’s knowledge. It is convenient to have all important documents in one place. Besides, we all like our geekbot in Slack that keeps us always on our toes. So our daily stand-up is a kind of small communication with the geekbot. We used to work in Trello to have all our tasks categorized into boards, but now we are switching to JIRA. This or that particular tool is of great benefit to the team, since we have a complete picture of the work to be done during a sprint. Fruitful sprint meetings motivate us and encourage all of us to work harder and move forward. Self-management brings its results as well, because team members organize their workflow and take on the tasks according to their capacity. Eventually, the velocity of a team is great, because we are not single-players, we are like a rugby team that moves the ball toward the goal quickly and efficiently.

Closing notes

Weighing all the pros and cons, you are to choose now whether you would prefer to implement Scrum practices in your company or not. Before making a final choice, please think again and answer the following questions: Would your company get benefits if you apply Scrum strategies? How long will you continue suffering from negative consequences of traditional methods if you don’t?