Scrum is a software development framework. You should not reinvent the wheel. How you should do scrum has been even explained by Kenn Schwaber and Jeff Sutherland in 1995 at the Business Object Design and Implementation Workshop in Austin. (Does it surprise you? Scrum is a “new trend” in previous years, even this method has been defined in the previous century, even in the previous millennium. Yeah, believe it or not…), and you can learn it. (Start here)

The beauty of this framework, that your team can adapt it the way, as it works the best for you. What you should focus on is to understand the basic principles, keep the framework, and implement the method what has been described. Trust in the process!

In the past years when I worked with different scrum Teams, we started the Scrum implementation with basic discussions, how we will do Scrum ant the result of these discussions were our teams 3 base documents.

1. Working agreement
2. Definition of readiness
3. Definition of done

 

Working agreement

This is the method how the daily routine for your Scrum Team will look line. What kind of meeting are you going to have? When the presence of the product owner is required or not? How do you communicate inside the team? Where do you store your documentation? What kind of tools are you going to use? Everything that you can imagine regarding the daily work.

This document should be discussed and prepared at the beginning when a scrum team formed and even start the first sprint. The first version of this document is not going to be perfect, and it will never be ready. Just imagine, how often does your team change (a new team member come, a team member leave the team). It can happen that the whole team changes in one year and an “old” working agreement which has been created by the people who worked in the team before will not fit for the newcomers.

The working agreement should be discussed during the retrospectives. All the changes which will be agreed on a retro must have been introduced into this working agreement.

 

Definition of readiness

This was the documentation which sets the expectations between the scrum team and the Product Owner. When a new requirement is ready for grooming? When a new requirement is ready for development? What kind of expectations do you have for the mentioned request? What kind of background should you provide? What kind of bug report does the scrum team need?

This can help the Product Owners and business people (like business analysts, systems analysts, etc.) to understand what kind of information needed for the scrum team to even jump in any development.

The definition of readiness also a discussion for a retro, but it needs to pull in before the grooming meetings or during the Sprint Plannings.

 

Definition of done

In the Scrum Guide, it has been explained why defining “Done” is necessary.

If the definition of done for an increment is part of the conventions, standards or guidelines of the development organization, all scrum teams must follow it as a minimum. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

For a team which I have worked with the definition of done included elements like development has been released, IT and Business documentation is ready, application/feature has been added to the monitoring system, etc.

Not every done element will apply for every work which you have finished. But all the done requirements should be reviewed for a development with your team. The best ceremony to use this document is the Sprint Planning session.

 

Hope this explanation help you a lot to champion your Scrum processes. I am interested what other “basic documents, founding stones” do you have. Share it in the comment section!