Very often a development team fears of estimating. But, even more often, business requires many different estimations (time, scope, etc.), as much precise as they could be. There are some useful planning and estimating techniques that could help.

As a developer, I wanted my job to be a game, so I can enjoy doing it. But if you want to play a game there are some rules to obey. The same goes with a methodology or a framework – you should obey some rules in order to get a successful implementation.

Scrum Master is a leadership role in Scrum. It is also a role with no authority over the team. However, when we talk about leadership, we are used to the model of command and control where leader “rules” with authority.

Conflicts show us that something is wrong and needs to be changed – hence the increased inspection and adaptation capabilities in Scrum teams. At the same time, different perspectives foster new ideas, options and insights, needed for great decisions necessary for developing great products.

Product Owner has a very difficult job of understanding requirements’ priorities from a customer’s point of view. Product owner’s job is to rethink what will bring the greatest value to a project and a customer, and to put these requirements at the top of the priorities list.

As, a Scrum Master, I have always pushed developers to protect the code quality. The Project Manager had forced the team to produce low-quality code. This made adding new features and understanding the code very difficult at times…

Scrum is a framework of practices tied together by small set of clearly defined rules. To correctly implement Scrum, it is important to follow the few prescribed rules and to work within the framework of practices.

We should spread decision making throughout the project, based on information which we have and we should do that often (inspect and adapt mechanism). This is where User Stories come in. User stories are Agile Requirement Technique very often used by Scrum teams.