[#]: collector: (lujun9972) [#]: translator: ( ) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) [#]: subject: (Small Scale Scrum vs. Large Scale Scrum) [#]: via: (https://opensource.com/article/19/3/small-scale-scrum-vs-large-scale-scrum) [#]: author: (Agnieszka Gancarczyk https://opensource.com/users/agagancarczyk) Small Scale Scrum vs. Large Scale Scrum ====== We surveyed individual members of small and large scrum teams. Here are some key findings. ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BUSINESS_crowdvsopen.png?itok=AFjno_8v) Following the publication of the [Small Scale Scrum framework][1], we wanted to collect feedback on how teams in our target demographic (consultants, open source developers, and students) work and what they value. With this first opportunity to inspect, adapt, and help shape the next stage of Small Scale Scrum, we decided to create a survey to capture some data points and begin to validate some of our assumptions and hypotheses. **[[Download the Introduction to Small Scale Scrum guide]][2]** Our reasons for using the survey were multifold, but chief among them were the global distribution of teams, the small local data sample available in our office, access to customers, and the industry’s utilization of surveys (e.g., the [Stack Overflow Developer Survey 2018][3], [HackerRank 2018 Developer Skills Report][4], and [GitLab 2018 Global Developer Report][5]). The scrum’s iterative process was used to facilitate the creation of the survey shown below: ![](https://opensource.com/sites/default/files/uploads/survey_process.png) [The survey][6], which we invite you to complete, consisted of 59 questions and was distributed at a local college ([Waterford Institute of Technology][7]) and to Red Hat's consultancy and engineering teams. Our initial data was gathered from the responses of 54 individuals spread across small and large scrum teams, who were asked about their experiences with agile within their teams. Here are the main results and initial findings of the survey: * A full 96% of survey participants practice a form of agile, work in distributed teams, think scrum principles help them reduce development complexity, and believe agile contributes to the success of their projects. * Only 8% of survey participants belong to small (one- to three-person) teams, and 10 out of 51 describe their typical project as short-lived (three months or less). * The majority of survey participants were software engineers, but quality engineers (QE), project managers (PM), product owners (PO), and scrum masters were also represented. * Scrum master, PO, and team member are typical roles in projects. * Nearly half of survey respondents work on, or are assigned to, more than one project at the same time. * Almost half of projects are customer/value-generating vs. improvement/not directly value-generating or unclassified. * Almost half of survey participants said that their work is clarified sometimes or most of the time and estimated before development with extensions available sometimes or most of the time. They said asking for clarification of work items is the team’s responsibility. * Almost half of survey respondents said they write tests for their code, and they adhere to best coding practices, document their code, and get their code reviewed before merging. * Almost all survey participants introduce bugs to the codebase, which are prioritized by them, the team, PM, PO, team lead, or the scrum master. * Participants ask for help and mentoring when a task is complex. They also take on additional roles on their projects when needed, including business analyst, PM, QE, and architect, and they sometimes find changing roles difficult. * When changing roles on a daily basis, individuals feel they lose one to two hours on average, but they still complete their work on time most of the time. * Most survey participants use scrum (65%), followed by hybrid (18%) and Kanban (12%). This is consistent with results of [VersionOne’s State of Agile Report][8]. * The daily standup, sprint, sprint planning and estimating, backlog grooming, and sprint retrospective are among the top scrum ceremonies and principles followed, and team members do preparation work before meetings. * The majority of sprints (62%) are three weeks long, followed by two-week sprints (26%), one-week sprints (6%), and four-week sprints (4%). Two percent of participants are not using sprints due to strict release and update timings, with all activities organized and planned around those dates. * Teams use [planning poker][9] to estimate (storypoint) user stories. User stories contain acceptance criteria. * Teams create and use a [Definition of Done][10] mainly in respect to features and determining completion of user stories. * The majority of teams don’t have or use a [Definition of Ready][11] to ensure that user stories are actionable, testable, and clear. * Unit, integration, functional, automated, performance/load, and acceptance tests are commonly used. * Overall collaboration between team members is considered high, and team members use various communication channels. * The majority of survey participants spend more than four hours weekly in meetings, including face-to-face meetings, web conferences, and email communication. * The majority of customers are considered large, and half of them understand and follow scrum principles. * Customers respect “no deadlines” most of the time and sometimes help create user stories and participate in sprint planning, sprint review and demonstration, sprint retrospective, and backlog review and refinement. * Only 27% of survey participants know their customers have a high level of satisfaction with the adoption of agile, while the majority (58%) don’t know this information at all. These survey results will inform the next stage of our data-gathering exercise. We will apply Small Scale Scrum to real-world projects, and the guidance obtained from the survey will help us gather key data points as we move toward version 2.0 of Small Scale Scrum. If you want to help, take our [survey][6]. If you have a project to which you'd like to apply Small Scale Scrum, please get in touch. [Download the Introduction to Small Scale Scrum guide][2] -------------------------------------------------------------------------------- via: https://opensource.com/article/19/3/small-scale-scrum-vs-large-scale-scrum 作者：[Agnieszka Gancarczyk][a] 选题：[lujun9972][b] 译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 [a]: https://opensource.com/users/agagancarczyk [b]: https://github.com/lujun9972 [1]: https://opensource.com/article/19/2/small-scale-scrum-framework [2]: https://opensource.com/downloads/small-scale-scrum [3]: https://insights.stackoverflow.com/survey/2018/ [4]: https://research.hackerrank.com/developer-skills/2018/ [5]: https://about.gitlab.com/developer-survey/2018/ [6]: https://docs.google.com/forms/d/e/1FAIpQLScAXf52KMEiEzS68OOIsjLtwZJto_XT7A3b9aB0RhasnE_dEw/viewform?c=0&w=1 [7]: https://www.wit.ie/ [8]: https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report [9]: https://en.wikipedia.org/wiki/Planning_poker [10]: https://www.scruminc.com/definition-of-done/ [11]: https://www.scruminc.com/definition-of-ready/