Yes why indeed? Not because you think you have to, or because everybody else is doing it. Only do it if there is a real problem that you want to solve. To name a few examples:
If you have problems with delivering software at the right time. If your projects spent too much money for too little value. If you think you can’t keep up with market trends.
Just bear in mind that Scrum is not the Holy Grail. It will not solve all of your problems, and when implemented badly it might very well make things worse.

If everybody in the team has the role of developer, how do you prevent somebody to develop a piece of code and deploy it to production himself?
There are several ways to mitigate this risk. Although everybody has the role of developer, you can still have multiple authorizations within the team. You can assign the authorization to deploy to production to a specific person, for example the Scrum Master. Another way is to make sure deployments can only happen through pre-defined processes, that preferably are automated. In these processes a lot of controls should be build-in to avoid misuse or mistakes. I will discuss more on this in the Continuous Delivery and DevOps parts of this website.

The result of every sprint is an increment, which is potentially shippable software. Weather the software will actually be release to the customer is a business decision. So no, you don’t have to go to production every sprint. But because you can, IT becomes a business enabler, instead of the department everybody is waiting for.

A user story can be seen as a requirement. It clearly describes what is needed for who and why. It is often written in the format: As a role I want something so that I can do some kind of benefit. User Stories can vary in granularity. If defined generally it is usually called an Epic. When User Stories are prioritized the team should refine them, so you end up with User Stories that can be implemented in one sprint. When selected for a sprint the Team defines Tasks to implement the User Story.

The Velocity of a team is the amount of Story Points the team can implement in one sprint. Unlike Function Points, Story Points are not comparable between teams. Every team build up its own measurement system for Story Points. Every team is challenged to improve their Velocity. The Retrospective is one of the instruments to achieve this.

Sure you can! But it’s not part of Scrum. Function Point Analysis is a method to measure software. To do this it breaks down the system into smaller components. FPA measures systems from a functional perspective, independent from the way they are implemented. The only variable is the amount of effort needed to implement the function points. So it can for example be used as a tool to compare the effect of different development tools. It is also used as a way to calculate project budget and throughput time of a project. Function Points can be used to compare between teams, which is not possible with Story Points. Note that FPA can only be done by experts. FPA offers features that Scrum does not have, so it can be beneficial to use it.

Excellent question!
Story points are a relative way to measure the effort it takes to realize a User Story. So why not use hours?
This is because every team member has different skills, which means the time it will take to realize a user story will differ per person. Rather than taking some kind of average value that does not means much, you want to measure the complexity of the User Story. It is much easier for team members to agree on the complexity of a Story than it is to agree on the number of hours. This is also the reason why you should not try to translate Story Points to hours. Quite often you see rules of thumb where one Story Point equals 4 or 8 hours. Try not to do that!
User Stories are the responsibility of the Product Owner. The PO decides on the priority of the User Stories on the Backlog Items. For the PO Story points are a better unit of measurement than hours, because he does not need to know how the stories are implemented. Every User Story is implemented by executing a number of tasks. Tasks define how the User Story is implemented and are the responsibility of the Team. Tasks are usually measured in hours and not in Story Points.

A Burn Down Chart is an instrument to track the progress of the team during a Sprint. It shows on a daily basis how much story points have been done. The chart shows if it is likely that the team is going to meet the Sprint Goal.


Note: some teams prefer to use a Burn Up chart, because that also shows the amount of work that has been added or removed during the sprint.

The Agile manifesto was introduced in 2001 as an answer to problems with the Waterfall approach. It consists of 12 principles to better cope with uncertainty, stimulate creativity and enhance effectiveness. Since the introduction many types of Agile methods surfaced, based on the Agile principles. Scrum is currently the most popular of them, mainly due to it’s simplicity. Other types are: Extreme Programming (XP), RUP, DSDM, Kanban and Lean Development.

Where Scrum is a process framework to manage complex product development, Extreme programming (XP) is a software development methodology. Both are based on Agile principles. XP takes out beneficial elements of traditional software engineering practices, and brings them to "extreme" levels. (Hence the name). Examples of these elements are: pair programming, code review and unit testing. The four basic activities of XP are: coding, testing, listening, and designing. Like Scrum XP is designed to improve on productivity, quality and adaptivity. But in XP changes are allowed during iterations. In Scrum the scope is not changed during the sprint. Iterations in XP can be even shorter than the sprints of Scrum and the order of the XP-backlog is more strict. And last but not least: XP describes engineering practices, where Scrum only focusses on the framework.

KanBan may look a lot like Scrum, but this is mostly because many teams use Scrum elements in their KanBan approach. KanBan is a LEAN technique that optimizes the flow of a process. Think of your process as an assembly line. By limiting Work In Progress KanBan optimizes the amount of output of the assembly line. Where Scrum periodically (every 2-4 weeks) delivers an increment, KanBan constantly delivers output. So out-of-the-box KanBan does not have sprints, stand ups, retrospectives, cross-functional teams and burn down charts. KanBan does not prescribe roles and events. Even prioritization of the backlog is optional in KanBan. KanBan does have a KanBan board that may look a lot like a Scrum board. The most important thing is that you limit the amount of tasks in progress. This forces the team to finalize the ongoing tasks before starting new tasks. So if you do not really deliver increments, and if you struggle with the duration of sprints. If you consider very short sprints. Or if you have a pretty standard process that constantly delivers output. Then maybe KanBan is a better choice than Scrum. The best way to find out is to experiment with it.

Prince2 is a process-driven project management methodology. It is based on 7 principles such as: Justification of the business case during the whole project, Manage by stages, and learn from experience. Prince2 is based on best-practices. A lot of focus is on planning and control. Prince2 can be an effective methodology to manage your project, but it is fundamentally different from Scrum. Personally I would not advice to mix these methods in one team. You could use Prince2 as a sort of governance wrapper for your Scrum activities. In this scenario you could do Scrum within the Prince2 stages. If this works for you, why not? Well... I think this kind of Water-Scrum will not give you the benefits that you might expect. My advice: Stick to one method and do it right!

That depends. Is your team also responsible for the Operations of the system? Are you in fact a DevOps team? In this case incidents will influence the current work, because some just have to be solved instantly. It could also be that the Ops team is requesting your help in solving an issue. You should consult the Product Owner, but in the end for you it’s just another scope change. Do remember that incidents come with strict time lines to solve. It might not even be your responsibility, but you do all work for the same company!

A lot! Most of the times culture has to change. And culture means behaviour of people. There will be opposition. People will mock it. Conservative parties will demand proof. They will want to see solid business cases before any approval is given. In the beginning it is often swimming against the current. You have to be determined. Don’t give up easily. Check out the Pitfalls for more details.

The Scrum Guide is very clear on this. Scrum is only Scrum if all parts are implemented. Every component of the framework is essential to the success of Scrum. Partial implementation is possible, but it will not be Scrum. Specific tactics on how to use Scrum are possible. Examples are: The way the team interacts during the sprint, the way the refinement of the backlog is done, or the way the team makes the sprint planning.

When you are doing fine without Scrum, there is no real reason to change. Scrum is difficult in combination with outsourcing activities and when the team is geologically dispersed. Some large changes in combination with strict deadlines and clearly defined results are better done with projects than Scrum. If there is not much uncertainty and changes in your project are not very likely, you might reconsider Scrum as the best alternative. Or maybe you already apply some sort of Agile method that does the trick for you. Scrum is not a silver bullet that solves every problem for you.

Of course it can! The problem is not Scrum itself. It’s the organization that can make it hard to implement Scrum. Often enough resistance is high against any change. People may not believe Scrum is going to work for them. Large organizations tend to think they are special, that general rules don’t apply to them. Other arguments you might hear are: Quality Control is too important for us to do Scrum, Our projects are too complex to do small increments in Scrum, Senior Management does not endorse Scrum. The best way to overcome this resistance is often to start small, and prove that it does work. So is it easy to implement Scrum in a large organization? Probably not. But is it possible? Certainly!

It may seem a little impractical to limit the team size to 9-10 people. Why not 11 or 15 or 20? If you have enough work, why not? Scrum Teams are self-organizing and cross-functional. They decide for themselves how to do the work. So too few people in the team is also bad. It is very likely a team of 2 or 3 will not have all the skills to deliver increments autonomously. If the team size goes above 9 the amount of coordination will be so high the team starts to be inefficient. Bringing in more people does not mean the team will deliver more work. Quite often the opposite applies. If you really have more work than a team of 9 can handle; split the team in 2 separate Scrum teams. And do not forget: experiment! Find out what the optimal team size is for your organization by trying different sizes. Remember Scrum is empirical.

See above. Start a new team, or prioritize the work.

So how should the work be divided amongst Scrum teams? Is it based on system architecture? Is it based on types of customers? Or maybe based on work flows? Again this is something you will have to find out for yourself. What works best for your organization? Just remember that teams should be as independent as possible from the rest of the organization.

Scrum does not describe how all the separate increments can be integrated. This is intentionally because the Scrum framework is lightweight and simple to understand. But large organizations may need more guidance. You might want to look at the Scaled Agile Framework (SAFe). One of the things it describes are Agile Release Trains (ARTs). ARTs are virtual organizations of 5-12 Agile Teams that plan, commit and execute together. So together these teams produce shippable products. For this to work the backlog does not only consists of User Stories. A set of User Stories can form a Feature that can be shipped in a release. Several Features can be defined as an Epic, which can be a more long-term goal. You can even assign Feature owners and Epic owners, next to the Product owners. Release planning sessions must make sure all the teams go in the same direction. Architects are assigned to steer the Release Planning sessions. SAFe can be a real help in scaling Agile Scrum to an enterprise level. Just be aware. Keep it all simple and lightweight. Before you know it you have recreated a large governance organization, and that is not going to help you in being agile.

Architects are not part of a Scrum team, but they are very important in steering the Scrum teams in the right direction. Architects define the frameworks in which the Scrum teams must deliver their increments.

If you need a DBA to deliver your increments, then yes. But if the DBA is only needed every now and then, it’s probably more efficient to use some kind of expert team.

Project Managers are not needed in Scrum. You can send them home or give them another job. Quite often Project Managers become Scrum Masters, but that is not always a good idea. Old habits die hard. Project Managers steer people. Scrum Managers must coach. If former Project Managers start to steer in their role as Scrum Master, the Development Team cannot be self organizing.

In Scrum accountability belongs to the whole team. To stress this point everybody in team has the same role. But this does not mean that everybody should have the same skills, or is doing the exact same work. It might not even mean that everybody is equal. A junior team member will have a different status than a senior team member. But still: in the end everybody in the team is accountable.
The team itself is responsible for organizing the work. So the developers can decide for example if everybody is testing code, or that this is done by some of the team members. As long as they understand that you can never hide. If any team member messes up a test, the whole team is responsible.

From a pragmatic point of view you could do this. But this is not best practice. Product Owner and Scrum Master are different roles that require different skills. The Scrum Master coaches the Scrum team, thus improving the capabilities of the team. The Product Owner sets the priorities based on his/her strategy, which is probably based on input from stakeholders. It is not very likely that one person will excel in both capabilities. Besides that it is also very important that Scrum Master and Product Owner help each other, also by challenging their points of view. Separating these roles will mostly lead to a stronger Scrum organization.

To make Scrum work the Scrum Master and certainly the Product Owner should have enough time to do the job right. A common pitfall is to assign people to the role of Product Owner besides their regular job. Another is to give one Scrum Master multiple teams. This usually leads to a lot of disappointments. When you start with Scrum assume that all roles are full time. Maybe later after a lot of experimentation it can be different.

Traditional management is not a role that is described in the Scrum Guide. So if teams are self organizing, can we do without management? The answer is: Most likely not. Somebody has to care of the HR in the team. Make sure the team has the right capabilities. And making sure people learn, develop and grow. The Scrum Master coaches the team, but he/she is not responsible for performance management.
Often enough somebody has to take care of Governance related matters. Somebody must make sure proper procedures are in place. And somebody must guide the organization during changes. All these things can be the responsibility of management.
But the hardest thing for management in Agile Scrum is letting go. Let the team be self organizing.

Security is a concern for the whole team, not one assigned individual. As such delivering secure increments should be part of the definition of done. Security should be a requirement that is embedded in the process from the beginning. Not something somebody is testing at the end. So a Risk Analysis could be done for every backlog item. And the validation should be in the process, preferably automated. It all starts with a proper security awareness in the team. Security is not a diversion from your regular work. It is your regular work!

Traditional Governance processes often conflict with Agile Scrum. Why is that? Governance is organized around the concept of predictable outcomes. First you explain exactly what you are going to do and when results are delivered (milestones). And secondly you have to explain how much money you need to accomplish this. After budget has been approved a process takes place where the progress of your promises is strictly monitored. All deviations must be explained and are mostly seen as bad management.
Scrum is very different, and it is obvious that this kind of Governance does not fit well with Scrum. But that does not mean Governance is the Mother of all evil. Governance also means inspecting, something Scrum is highly advocating. Just inspect on the things that matter. Maybe inspect on the delivery of the backlog, or on the added business value.
If you have to deal with a more traditional Governance process, you need to compromise. Say something about expected results, but keep Governance closely aligned. Show them that change is not bad. And of course: share success!

In Scrum Quality Control is not an activity that is done after the product has been delivered. It should be incorporated in the whole process from start to finish. At the start the team must specify how inspection will be done. So Quality Control starts when the User Stories are defined.
All functional and non-functional requirements must be tested. Make sure the Definition of Done enforces high quality standards. You don’t really need a QA person in a Scrum team, but if everybody agrees that this will help it is a possibility. Just make sure Quality is the responsibility of the team. It can’t be delegated to a QA person.

The Scrum framework does not say much about automation. But it obviously makes sense to automate manual tasks to speed up the delivery process. This will help to achieve short delivery cycles with fast feedback. Scrum fits very well with concepts as Continuous Delivery and DevOps. More about automation will be discussed there.

No! Documentation is still very much needed. Scrum just considers working software more important than documentation. But this certainly does not mean that documentation is not needed. Documentation may very well be a part of the Definition of Done.

Scrum teams should sit together and work in close collaboration. So outsourcing part of the work is not going to help. But you can still use a lot of Scrum techniques to improve collaboration between the teams. Suppose you have outsourced development work, but testing is done in-house. At first glance this has nothing to do with Scrum where development and testing are not so strictly separated. But a daily stand-up via video conferencing can help to improve communication. Working in sprints helps with faster feedback. And doing Retrospectives together can really improve the way of working.

Everybody who is working with Scrum should have a good understanding of the Scrum Framework. Scrum Masters and Product Owners can study for an official certification. This is really important. If people do not really know the framework, all kinds of interpretations and misunderstandings can take place. The Framework is deliberately kept simple. But that means that a profound understand of it is crucial for success.

You do not necessarily need a tool to do Scrum. Many tools are available to support Scrum. For enterprises tools like Jira, Rally, VersionONE or Agile Cockpit can be a big help. But there are downsides. These tools try to be so versatile that they tend to be rather complex. Quite often they use their own lexicon, which can be confusing. But there are also simple tools like Scrumwise and Agile Bench. Less versatile, but much easier to use. What tool to choose depends on what you want to do with it.
My advice: Start without any tool. After a while evaluate where a tool can really improve the process.

Well in theory this is simple. The Development Team identifies the impediments, and discusses them mostly during the stand up. The Scrum Master removes the impediments. In practice you have to be careful: The Scrum Master is not the dirty job guy. See also in the Pitfalls section.

Quality goals do not decrease, that should be very clear. And the sprint is not extended, not even with one day. It always ends at the agreed upon moment. This means that some of the work may not be done. If this is the case it is send back to the backlog, and does not automatically transfer to the next sprint. The Product Owner has to decide on the priority again.

New items may be added to the sprint backlog during the sprint, as long as this does not endanger the sprint goal.

Oh yes! Many many more. But I think we are good for now.