While there are some good books on Scrum out there, we believe none of them deal with all the essentials a software project team needs to know in order to begin and complete a Scrum software project within corporate constraints (by corporate constraints, we mean in companies where Scrum or Agile has not been successfully deployed enterprise-wide).
In order to help these teams succeed, sometimes in navigating treacherous corporate constraints, we set out to write a practical book on Scrum using the knowledge we essentially acquired from the trenches.
To this end, the 15 chapters of this book will provide you with all the knowledge you need as if an experienced ScrumMaster were advising you in person. In addition to this, you will also find in Appendix A two case studies for two software products that had been successfully built and deployed using the techniques and advice outlined in this book.
Chapter 1: Setting the Stage: Agile and Scrum
Chapter l’s focus is the foundation of Agile with emphasis on Scrum as part of the Agile family. Chapter 1 also serves as an introduction to the fundamentals of Scrum and corrects some of the inaccurate information about Scrum, more or less like Alan Shalloway and his team did in Lean-Agile Software Development Achieving Enterprise Agility (p. 84–92). This is a way for us to get you on the same page with us before we move forward.
Chapter 2: Finance Speak
Whether you are passionate about Agile and Scrum or not, one thing to remember is that the language of business management is finance.
In Chapter 2, you will learn the essentials of finance, what you should know in order to better collaborate with business management in helping them select projects, estimate a project budget, and forecast how much money and time you will need to finish your project.
Chapter 3: Secure Top Management Support but Make Sure to Obtain Middle Management Buy-In
Although it is important to work with top business management to get their approval, it is even more important to work with middle management on a daily basis since middle management is where the rubber meets the road. The goal of Chapter 3 is to give you enough knowledge to be successful at both.
Chapter 4: A Visual Requirements Gathering for the Product Backlog
Once the approval is given to a project team to move forward, there is nothing more important than a good set of requirements. Chapter 4 presents a very simple and visual process to gather requirements for a Scrum project that any of us can use.
Chapter 5: Making the Story Point Estimate Comparable for Scrum Enterprise-Wide Implementation
As Agile and Scrum become more and more widely accepted, one of the problems we encounter with the current story point system (upon which team velocity is built) is that it does not allow for comparison between teams. This hinders many IT departments’ desire to implement Scrum across the board, especially when it comes to overall resource allocation and re-allocation. As in Chapter 4, we present here an approach that has been successfully used on many projects. It will help you estimate your stories and back up what you say, not with your gut feelings but with tangible data as well as make it possible to compare velocity between different teams within the same organization.
Chapter 6: The Influence of Architecture Vision on Team Velocity and Software Quality
For anyone who has ever worked on even one single Scrum project, you should have seen that team velocity fluctuates up and down, often reducing team productivity and ability to deliver. This chapter will walk you through the reasons for fluctuations in team velocity; and it will suggest how to use architecture vision, similar to what others call architecture intent, to remedy it.
Chapter 7: From Architecture Vision to Release and Sprints Planning to Parallel Software Development
In addition to the fact that it can help team velocity, or even increase it over time, a good architecture vision has additional benefits. This may include a positive impact on release and Sprint planning.
Chapter 8: Did You Say Product Owner?
Everyone is important on a Scrum project, but the product owner is the person who can help the team deliver the most value for the business. Chapter 8 reviews the personal and professional qualities a product owner should have to be successful.
Chapter 9: The Importance of Automated, Regression, and Integration Tests
Not all testing is created equal. In this chapter, we will provide an in-depth treatment of a few tests that are, in our opinion, most important to Scrum projects, and explain why they are key to a successful Scrum project team.
Chapter 10: The Importance of Teamwork
Who among us has not heard about teamwork and how important it is. Even if it sounds like an old cliché, Chapter 10 affirms that teamwork is essential in order for the Scrum team to deliver value, especially since the team is now self-organized. Beyond saying that teamwork is important, this chapter offers some insight into human psychology and temperament types that can help co-workers better understand one another and work well together. In addition, this chapter also offers some techniques for conflict resolution, taking into account the stage at which the conflict happens on a project.
Chapter 11: The New Nature of Management and Leadership on a Scrum Project
Even though Scrum teams are self-organizing, there is still a need for project management and team leadership. The ways that project management morphs into something a bit different in the Scrum environment will be explored. The key thing to remember here is that servant leadership will replace the command and control style of the past. Chapter 11 reviews some useful coaching and leadership techniques for Scrum Masters and product owners as they team up to help guide the team toward their final project delivery.
Chapter 12: How to Adapt Scrum (Without Destroying Its Agile Foundations or Doing Negative ScrumButs)
Wouldn’t it be wonderful if someone could invent a methodology or process that could fit every company and every problem, that we could use without ever having to adapt it to our environment? The reality is that we must often adapt the methodology to our constraints, to get it to work. This is also true with Scrum.
Unlike the negative “ScrumButs,” which are wrong applications of Scrum, we will review here several examples of positive “ScrumButs,” or good adaptations of Scrum, in the same way as Jurgen Appelo, CIO at CSM eCompany in the Netherlands, did in his “ScrumButs are the best part of Scrum”.
Chapter 13: Scrum Project Readiness Self-Assessment
Chapter 13 provides an example of a Scrum project readiness self-assessment, which you should try to fill out at the very beginning of your Scrum project. This will allow you to identify where the obstacles may be which could hurt your project team’s ability to deliver.
Depending on your score, you will know how easy or how hard it is going to be for your team to perform within your current environment and try to improve it so that you can deliver more readily.
Chapter 14: When Do You Need a ScrumMaster?
Unless you or your team is experienced with Scrum, you will need a ScrumMaster to guide you through some of the tribulations that will accompany your first attempts with Scrum.
Even though this book is supposed to serve as your ScrumMaster, Chapter 14 reviews the personal and professional qualities a ScrumMaster should have to be successful.
Chapter 15: Parting Thoughts
Rather than just let you move ahead alone, Chapter 15 provides some suggestions as to what main applications you should draw from the different chapters and the order in which you should apply them to your project situations.
Appendix A: Two Real-World Software Product Development Case Studies
In Appendix A we showcase two successful software products that were built and deployed using the advice given in this book, from requirements gathering to architecture vision to release and Sprint planning and testing.
The first case study provides an example of an application that is developed vertically, while the second case study provides an example of an application that is developed horizontally.
Appendix B: Could You or Should You Have an Abnormal Termination of a Sprint?
Normally, your Scrum project should go smoothly if you have followed all the advice we have given in this book. This being said, there may be instances where you will be experiencing what is called an abnormal termination of a sprint, which is due sometimes to your underestimation of your team’s velocity or the complexity of some of your user stories.
To advise you in what to do in this situation, included in this book is also a small chapter on the abnormal termination of a sprint, what the causes are, how to avoid it, how to deal with it and how to restart the project team’s work after one.
Depending on your title or the role you have in your current organization, here are some suggestions as to what chapters you should read and in what order. There are two kinds of people who will find this book useful: (1) those who are new to Scrum and (2) those who already have some experience with Scrum.
As you are part of management, you should first read Chapter 1 to get familiar with the Agile evolution, how it got started and with Scrum origin as well as its basics. Next, you should read Chapter 3 to see what advice we give to the Scrum team to work with management, with both top business management and middle management. Next, you should read Chapter 8 and Chapter 14, respectively, on the product owner’s and ScrumMaster’s quality and role.
Scrum or not, we guess you should wonder how you or your team is going to gather requirements for the so-called product backlog which you have heard so much about. If this is the case, then the next chapter you should read is Chapter 4 on how we identify user goals and use a visual technique to gather requirements for Scrum projects. You may also have heard that with planning poker every team’s velocity, which is the number of user stories a Scrum team can deliver for every Sprint, is different from one team to another. If this is what you have heard and if you wonder how you could make it comparable for a large-scale implementation across many teams, then you may want to read Chapter 5. It is effectively in Chapter 5 that we present a straightforward way to estimate your requirements, which will make it possible for every team member to back up their estimate and to make the team velocity comparable. This latter is, without any doubt, a key condition for a successful enterprise implementation of Scrum across many teams.
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
As you are part of management, you should first read Chapter 1 to get familiar with the Agile evolution, how it got started, and with Scrum origin as well as its basics. Next, you should read Chapter 3 to see what advice we give to the Scrum team to work with management, both top business management and middle management. Next, you should read Chapter 8 and Chapter 14, respectively, on the product owner’s and ScrumMaster’s quality and role.
Scrum or not, we guess you should wonder how you or your team is going to gather requirements for the so-called product backlog which you have heard so much about. If this is the case, then the next chapter you should read is Chapter 4 on how we identify user goals and use a visual technique to gather requirements for Scrum projects. You may also have heard that with planning poker, every team’s velocity, which is the number of user stories a Scrum team can deliver for every Sprint, is different from one team to another. If this is the case and if you wonder how you could make it comparable for a large-scale implementation across many teams, then you may want to read Chapter 5. It is during Chapter 5 that we present a straightforward way to estimate your requirements, which will make it possible for every team member to back up their estimate and to make the team velocity comparable. This latter is, without any doubt, a key condition for a successful enterprise-wide implementation of Scrum.
Since you come from a technical background, we next suggest that you read Chapter 6 on architecture vision and how it can help your team maintain a good velocity and even do a better job at release and Sprint planning (Chapter 7).
If you want to know who is going to drive requirements and the business needs in Scrum, then Chapter 8 on the product owner is for you. Likewise, if you want to know who will be responsible to help the team and the product owner understand and properly apply Scrum, then you will want to read Chapter 14.
Without having to get your hands dirty anymore since you are part of management, you may still want to read Chapter 9 to know what the three most important tests are for us and how to get organized to help your team or organization to deliver. As a member of the management team, we guess you should be curious to know how the team is going to be managed since you have heard that they are now self-managed in Scrum. If this is the case, then Chapter 10 is for you to read. Naturally, since you are a member of the management team, we next suggest that you read Chapter 11 on project management and team leadership. As any seasoned professional who is part of management, you know for a fact that no process or process framework could easily fit into an organization without a certain amount of adaptation. If this is the case, then Chapter 12 is the chapter you should read next. After this, if you wonder how you know where you stand with Scrum, then Chapter 13 is what you will want to review and start using the questionnaire.
Last but not least, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
Since you are someone who may be asked to act as the ScrumMaster on the project and since you are somewhat part of management, or should we say that as a project manager you likely have the same concerns as management, we suggest that you read the entire book.
You will be surprised to see how much you have learned about Agile and Scrum to understand what experts talk about and how to move forward in all confidence.
Since you are part of the technical team, we make the assumption that you are interested mainly in the chapters that can help you understand how to get the development job done. If this is the case, read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 8 (Did you say product owner?)
Chapter 9 (The importance of automated, regression, and integration tests)
Chapter 10 (The importance of teamwork)
Chapter 14 (When do you need a ScrumMaster?)
Now, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A, where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum to understand what experts talk about and how to move forward in all confidence.
Like the developer, we make the assumption that you are mainly interested in the non-technical chapters that can help you learn to know what Scrum is and how to get the job done. If this is the case, read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 2 (Finance speak)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 8 (Did you say product owner?)
Chapter 10 (The importance of teamwork)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 14 (When do you need a ScrumMaster?)
If you have some technical background or time, we recommend that you also read Chapters 6 and 7 on architecture vision. We have written them in such a way that they are also understandable to the non-technical team members. They will provide you with the same understanding as the technical folks on the team, allowing you to have the best collaboration with the technical folks.
Now, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased.
Like the developer and the business analyst, we make the assumption that you are mainly interested in the chapters that can help you learn to know what Scrum is and how to get the job done.
If this is the case, read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 9 (The importance of automated, regression, and integration tests)
Chapter 10 (The importance of teamwork)
Chapter 11 (The new nature of management and leadership on a Scrum project)
If you have some interest in knowing how your colleagues gather requirements and do their estimate on a Scrum project, read Chapters 4 and 5. If you have some technical background, we recommend that you also read Chapters 6 and 7 on architecture vision. We have written them in such a way that they are also understandable to the non-technical team members. Try to read them and you will not regret it since they will provide you with the same understanding as the technical folks on the team, allowing you to have the best collaboration with the technical folks.
Now, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
Like the developer and the business analyst, we make the assumption that you are mainly interested in the chapters that can help you understand what Scrum is and how to get the job done.
If this is the case, read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 10 (The importance of teamwork)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Next, read Chapter 3, especially section 3.3.
Now, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
Unlike the developer, tester, and the business analyst, as an enterprise architect you are mainly interested in ensuring that the Scrum project architecture fits into the overall enterprise architecture. For this, read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 8 (Did you say product owner?)
Chapter 10 (The importance of teamwork)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 14 (When do you need a ScrumMaster?)
Next, read Chapter 3, especially section 3.3.
Now, if you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
As your team is interested in IT alignment on business needs and in IT performance, you will want to read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 2 (Finance speak)
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 8 (Did you say product owner?)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 12 (How to adapt Scrum)
Chapter 13 (Scrum project readiness self-assessment)
Chapter 14 (When do you need a ScrumMaster?)
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
As your team is responsible for the daily running of the organization’s software applications, you will want to read:
Chapter 1 (It is all about Agile and Scrum)
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 8 (Did you say product owner?)
Chapter 9 (The importance of automated, regression, and integration tests)
Chapter 14 (When do you need a ScrumMaster?)
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
For the responsibility you have on the business of the project, read:
Chapter 8 (Did you say product owner?)
Chapter 2 (Finance speak)
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 9 (The importance of automated, regression, and integration tests)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 14 (When do you need a ScrumMaster?)
If you are interested in seeing the team build a robust application that does not break after you go live, we suggest that you read:
Now, if you have more time available, we suggest that you read the book as a whole, from start to finish. You will be surprised to see how much you have learned about Agile and Scrum.
As the person who is behind the business needs for the project and who provides the main funding for it, you should be interested in reading:
Chapter 1 (It is all about Agile and Scrum)
Chapter 8 (Did you say product owner?)
Chapter 2 (Finance speak)
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 14 (When do you need a ScrumMaster?)
If you have more time available, we suggest that you read the book as a whole, from start to finish, including Appendix A, where two examples of two software products that had been built and deployed using the advice given in this book are showcased. You will be surprised to see how much you have learned about Agile and Scrum.
As an experienced ScrumMaster, you should read:
Chapter 14 (When do you need a ScrumMaster?)
Chapter 2 (Finance speak)
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 12 (How to adapt Scrum)
Chapter 13 (Scrum project readiness self-assessment)
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased.
As an experienced product owner, you should read:
Chapter 8 (Did you say product owner?)
Chapter 2 (Finance speak)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 11 (The new nature of management and leadership on a Scrum project)
Chapter 13 (Scrum project readiness self-assessment)
Chapter 12 (How to adapt Scrum)
Chapter 14 (When do you need a ScrumMaster?)
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased.
If You Are a Member of the (Development) Team
Even though you have had some experience with Scrum, you may find something interesting here in reading:
Chapter 3 (Secure top management support but obtain middle management buy-in)
Chapter 4 (Requirements gathering for the product backlog)
Chapter 5 (Estimating user stories to make the story point comparable for Scrum enterprise-wide implementation)
Chapter 6 (The influence of architecture vision on team velocity and software quality)
Chapter 7 (From architecture vision to release and Sprints planning)
Chapter 8 (Did you say product owner?)
Chapter 9 (The importance of automated, regression, and integration tests)
Chapter 10 (The importance of teamwork)
Chapter 13 (Scrum project readiness self-assessment)
Chapter 14 (When do you need a ScrumMaster?)
If you have more time, we suggest that you read the book as a whole, from start to finish, including Appendix A where two examples of two software products that had been built and deployed using the advice given in this book are showcased.