Team work management through Scrum

An Erasmus+ project

A complex process called software development

Since the universe we live in is extremely complex, it is not surprising to have a complex pro-cess like developing software. Some processes like pressurized carbon turning into diamond hap-pen by themselves. On the other hand, the process of developing software is highly intellectu-al.

When software products succeed, meaning they meet the needs of the users, people’s lives change for better. However, when software fail, bad things happen. The pursuit of developing good software requires discipline considering the process of software engineering involves solving complex problems. Numerous rules and standards that are not only from technology point of view but add to that the most complex organism on the planet called human.

Since most of the intellectual and creative aspect of software development comes from hu-man, teamwork is a necessity for software intensive organizations. The ability to unite a team and consequently the teams within an organization is crucial in developing a successful project. Leader-ship and management are at the core skills that raise unity as well as productivity towards devel-opment of high quality software.

Software vision

A predictable software functions smoothly without errors and delivers the expected function-alities. Businesses, consumers and governments buy software systems as products. Customized software development, software products range in size from millions of lines of code in large-scale business systems to a few hundred lines of code in a simple app for mobile phones. (Sommerville, 2019)

Ian Sommerville proposes these three fundamental questions for finding product vision:

  1. What is the product that you propose to develop? How this product differs from competing products?
  2. Who are the target users and costumers for the product?
  3. Why should costumers buy this product?
The first question helps to clarify what you should do before you decide developing software. The other two questions target the product’s viability in the market. Most products are for costumers outside of the development team. The understanding of the costumer’s wishes and expectations play a significant role in defining product’s vision.

Some may believe that costumers are responsible for the product’s vision. This may be practi-cal for large enterprises but it is impractical in small software companies. In startups, the source of the product’s vision is the founder’s original idea as a solution to a problem that potential custom-ers have. This vision develops further long before a product manager is appointed.

PMs are responsible for managing the product vision. During development process, proposal for changes by developing team and costumers are inevitable. PMs have to compare the proposed changes against the product’s vision and the current working pipeline that the team is working on. They have to ensure that there is no “vision drift,” in which the vision is gradually extended to be-come broader and less focused. (Ian Sommerville, 2019)

Once the product manager takes the lead in developing the product vision. Market research and customer information brings even more changes. As Ian Sommerville states in his book called engineering software products, “I believe all team members should be involved in vision de-velopment so that everyone can support what is finally agreed. When team owns the vision, eve-ryone is more likely to work coherently to realize that vision.”

Software development process

“Much of our society depends on processes that work because their degrees of impre-cision is acceptable. Wheels wobble, cylinders shake, and brakes jitter, but this all occurs at a level does not meaningfully impede our use of a car. When we build cars, we fit parts together with a degree of precision fit for their intended purpose. We can manage many processes be-cause the accuracy of result is limited by our physical perceptions.” (Schwaber, 2015)

In software engineering, a process is not a strict predefined systematic plan. Rather, an adapt-able approach enabling the people doing the work (the development team) to choose the appro-priate set of work actions and tasks. The objective is to deliver software in a timely manner with sufficient quality to satisfy the buyers as well as users.

A process is a collection of activities, actions, tasks that are performed when a product is to be created, in this case software. An activity serves the purpose of achieving a broader target (e.g. communicating with costumers) and is applied regardless of the domain, size of project, complexity of effort, or the degree of precision. An action (e.g. architectral design) consists of set of tasks that produce a major work product (e.g. an architectural design model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.


Complex problems are those that behave unpredictably and the ways in which they behave are impossible to predict. In other words, a statistical sample of the operation of these processes will never yield meaningful insight into their underlying mathematical model. Furthermore, at-tempts to create a sample is only possible through summarizing operations to such a degree of coarseness as to be irrelevant to those trying to understand or manage these processes. In Figure 1, the vertical axis resembles requirements complexity and the horizontal axis represents complex-ity of technology. The intersection of the two kinds of complexity defines the total level of com-plexity of the project. (Schwaber, 2015)

Software development process consists of three dimensions. Users, developing tools and de-signers. Users as the most decisive factor in this process require certain functionalities that design-ers must understand. Developing tools enable designers or engineers to deliver the functionalities users expect. Among existing Software Development Life Cycle (SDLC) models such as Waterfall, Scrum, etc. All of them follow six steps namely as requirement analysis, specification analysis, sys-tem design, development, test and implementation.

“There are many stakeholders who have different needs and whose needs frequently change and are difficult to articulate. In most cases, these customers really start to understand what they want when they are provided with someone else’s impression of what they want. Theirs are complex requirements because theirs is not only ambiguous, but also constantly changing.” (Schwaber, 2015)

Technology involved in software development is advanced and often unreliable so that one can define the process of software development as the application of advanced, often-unreliable technology to solve business problems and achieve competitive advantage. Add to these the third dimension, which is the most complex organism on the planet, people. The complexity of develop-ing software raises even higher. (Schwaber, 2015)

Process control

Figure 2 Software development pro-cess
Software processes are interleaved technical, collaborative and managerial activities and the knowledge in these aspects is crucial in process of developing software with the overall goal of specifying, designing, developing, testing, and implementing a software system. Software developers use a variety of different tools in their work.

What happens when we are building something that requires a degree of precision higher than that of averaging? What happens if any process that we devise for building cars is too imprecise for our customers, and we need to increase the level of precision? In those cases, we have to guide the process systematically, ensuring that the process converges on an acceptable degree of preci-sion. Laying out a process that repeatedly will produce acceptable quality output is defined process control. When defined process control is not achievable because of the complexity of the interme-diate activities, something called empirical process control has to be employed. (Schwaber, 2015)

“It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” (Ogunnaike and Ray, 1992)

Teamwork management through Scrum

In any software business, managers need to monitor processes, which gives them the possibil-ity of predicting failure. As describes in engineering software products, by doing so, not only they can take measured steps and raise the odds that a project is likely to deliver the software on time but also they can finish the project within its budget. Traditionally, managers draw up a project plan consisting of a set of milestones, deliverables, and deadlines. The “grand plan” for the project shows a set of milestones (achievable goals), deliverables (what the team will deliver), and dead-lines (when a milestone will be reached).

An advantage of scrum is that it facilitates empirical process control. The reason for that is de-veloping a successful software in the first attempt using empirical process is much cheaper than the cost of reworking an unsuccessful attempt using defined process controls. The problem with up-front project planning is that it involves making detailed decisions about the software long be-fore implementation begins. Inevitably, things change, new requirements emerge, team members may change and above all, business priorities evolve. Redoing a finished work leads to project be-ing too expensive or too late to deliver.

Agile methods

Developers of agile methods preferred incremental planning to plan-based management that consists of wasteful and unnecessary activities. Agile methods focus on plans that can adapt chang-ing circumstances. At the start of each development cycle, decisions are made on what features should be prioritized, how these should be developed and what each team member should do. Planning should be informal with minimal documentation and with no designated project manag-er.

Figure 5 Scrum's Principles (Satpathyt, 2014) accessed

This informal approach in agile methods lacks the broader business need of progress tracking and assessment. Senior managers do not participate in detailed discussions with team members, alternatively, they want someone who can report on progress and take their concerns and priori-ties back to the development team. They need to know whether the software will be ready by the planned completion date and relevant information in case they need to update their business plan for the product. (Sommerville, 2019)

Scrum’s skeleton

Scrum the name derives from a rugby term used when teammates surround the ball and try aggressively to move downfield. Jeff Sutherland and his team develop the Scrum methodology in early 1990s. Furthermore, Schwaber and Beedle have developed the method during the recent years.

The need to for a more proactive approach to agile project management led to development of Scrum. To separate itself from traditional approach, Scrum named the link between the devel-opment team and the organization ScrumMaster and Product Owner.

“Scrum hangs all of its practices on an iterative, incremental process skeleton.” (Schwaber, 2015)

Figure 4 Scrum Process (Schwaber & Beedle, 2011) Accessed:

In Figure 4, the lower circle indicates an iteration of development activities occurring one after another, usually for one week to one month, leading to an increment of product. The upper circle resembles the daily inspection that occurs during the iteration. The goal of inspection is to allow individual team members to meet and inspect each other’s activities and make appropriate adap-tations. The process of iteration is driven by requirements and project funding and as long as there is funding the project can continue.

Terms Definitions
Product back-log A list of features, improvements and fixes that Scrum team has not completed.
Sprint A short period (two to four weeks) during which a product in-crement development takes place.
Scrum A daily team meeting where progress is reviewed and up-coming work is discussed.
Potentially shippable product in-crement The output of a sprint with high enough quality to be deployed for costumer.
Velocity Estimate of how much work development team can do in each sprint.

Development team

At the heart of the solution is the development team. Their work centers on delivering the result of each sprint (roughly between 2 to 4 weeks). Once the product backlog is ready for the next sprint, the team mutually commits to develop the product backlog into a potentially shippable product at the end of the sprint. Once the team commits, the time starts and the sprint becomes a time box in which the team can do whatever it takes to meet its commitments.

Scrum’s productivity stems from doing the right things first and doing them very effectively. The responsibility of maximizing efficiency is not for ScrumMaster and nor for Product Owner. The development team is also responsible for its own efficiency and their ability to manage themselves in meeting the objectives. (Schwaber, 2015)

To put things in perspective, the responsibility of self-management is a positive strategy con-sidering the survey made by Warden and Nicholson in 1996, which targets the motivation in IT staff. “IT is not a close-knit community of like-minded professionals. Many negative attribu-tions are made about other groups lacking the motivation for quality. Senior managers are ac-cused of paying lip service to quality, while starving it of resources in pursuit of profit. Software developers are accused of focusing on technical excellence, completely disregarding custom-ers’ need for a quality product. Customers are accused of demanding levels of quality, which they are not prepared to pay for. These are among the most common criticisms but there are many others. Each group within the profession makes negative attributions about other groups.”

Development team consists of software engineers and testers also known as Builders-as Evans describes in her book achieving software quality through teamwork- whom are people who speci-fy, design, and build and test the software. This includes the development team. The people in this group includes business and system analysts, software architects, designers, software engineers, programmer, developers, technical writers as well as testers. They are stakeholders for quality because they build quality into the product. They wrestle with difficult problems as they create new products.


ScrumMaster’s role is facilitating scrum projects. Why such as name? Since the responsibilities differ from Project managers, the difference in terminology comes as a symbolic one. ScrumMas-ter’s authority is indirect and largely shines by guiding the team within Scrum rules and practices. The main responsibility of ScrumMaster is to make sure that Scrum is followed throughout the de-velopment process and within the Scrum team. ScrumMaster fundamentally is a team coach who guides the team in the effective use of Scrum practices and guidelines. “While Scrum is easy to learn and adapt but many fail to make a good ScrumMaster” (Schwaber, 2015)

ScrumMasters are the champions of agile who make sure that Scrum works smoothly. They take care of scheduling ceremonies and carrying them out all the way to the end. ScrumMasters are also actively ensuring that the demos are as effective as possible when it comes to impressing the costumers. Moreover, ScrumMaster pays attention to newly added user stories and makes sure that new user stories do not impede user stories of higher priority and that Product Owner will notice the

Product Owner

Product owner is responsible for ensuring that the development team always focuses on the product they are building rather than diverted to technically interesting but less relevant work. In other words, PO is a team member who is responsible for identifying product features and attrib-utes. The product owner reviews work done and additionally, helps to test the product. In product development, the product manager should take on the role of a product owner role. (Sommerville, 2019)

POs are close to the team when capturing ideas. They are the main role behind prioritizing items on the backlog and they can approve user stories sometimes during the Demo. It is essential that the Product Owners attend every ceremony that they are expected to be in and make them-selves available for consultations. The expectations for availability of this role should be written out in the start of the project because these people are usually hard to reach. (Vanderjack, 2015)

POs rely on collaborative activities, because of their responsibility to capture ideas and creating sprint plans with the development team and ScrumMaster. Activities such as creating personas, transforming them to epics and finally generating user stories from the mist of ideas are effective practices in Scrum teams. The result is clear descriptions of the software requirements to plan first and following sprints.

From Personas to User stories

For writing the right user stories, the Scrum team needs to understand the target users and customers. User stories tell a story about the users using the product. If you do not know the users and what problem we want to solve for them then it is impossible to write the right stories and the team ends up with a long wish list rather than a description of the relevant product functionali-ty.

Personas offer a great way to capture users or costumers with their needs. They are fictional characters with imaginary names and pictures. Moreover, relevant characteristics such as role, ac-tivities, behaviors, attitudes and a goal (a problem that should be solved or a service to be provid-ed).

This template is designed by Roman Pichler is simple yet effective. It includes picture and name on the left. Description in the middle and goal on the right. It is important to create the primary character whom the product is mainly targeting. Once the personas have been developed, the next step is to derive Epics from the persona’s goals.


The purpose of epics is to capture functionalities as coarse grained, high-level stories according to Roman Pichler. Starting from the primary character, write all the epics required to meet the per-sona goals. Epics are sketchy ideas and do not include detailed technical requirements.

Figure 6 from personas to Epic (Pichler, 2014)
In the case of Skater app, an epic could be to choose from various characters to play the game. Another epic could be to play with friends and furthermore we can add another epic such as posting game results to social media. Epics are useful to capture functionalities of software products yet there are more steps before the development team can start creating the code.

Epics need to capture user’s interaction with the product and the steps in which different steps are taken to be able to interact with the product this requires initial visual design of the product. Furthermore, nonfunctional qualities (e.g. systems integration and performance) are within the context of writing useful epics. Use of diagrams, storyboards and sketches can be major progress at this stage.

Epics to User Stories

Figure 7 Refining epics into user stories (Pichler, 2014)
Epics provide a holistic yet coarse-grained description of the product. Once you have good description of the product, start refining the epics into user stories. Instead of writing all the stories at once, derive them systematically as depicted in Figure 7.

The goal of this phase is to gather enough user stories for the next sprint to deliver enough functionality and in time, therefore it is not required to derive as many user stories as possible. One of the advantages of using this approach is reducing the items in your product backlog.

Ideally, the product backlog should address the key risks; you may start pre-writing user stories and have a larger inventory of detailed items since your backlog is unlikely to change significantly during the incremental development of the product.

As a rule of thumb, stories should have three qualities before the development process can start. Moreover, in the final stage of generating user stories, the team needs to make sure each story has clear, feasible and testable characteristics. Such qualities help to fit stories that are small enough for the development team to carry them out during one sprint, implying the user interface design, test, and documentation work can be carried out.

Software engineering teamwork

Professional software develops by project teams ranging from two to few hundred people. It is clear that many people cannot work on the same problem therefore there is a need to split into number of groups and each group being responsible for developing part of the final system. When small groups are formed, communication issues are reduced and the whole team can get around a table and discuss the issues regarding the project. (Sommerville, 2019)

Software Engineering Institute devel-oped Team Software Process (TSP) in 2003 according to which, the software projects fail because of teamwork problems and not because of technical issues. Furthermore, Watts Humphrey points at ineffective leadership as a key problem for teams (Humphrey, 2000). The STP indicates that es-tablishment of goals, the clear definition of team roles, the assessment of risks and team plan are required for software teams to succeed. Moreover, according to the capability maturity model published by Software Engineering Institute in 2003 process structure should be sensible from the business and technical point of view. Teams however, ought to be self-directed by means of plan-ning and tracking their own work. Managers on the other hand are responsible for coaching and motivating the teams.


Overview – In this workshop where we will break into teams and guide everyone along each step of the process. You will create a story mapping on the walls and layout your user stories with priorities and business values to determine your first sprint plan.

00:00 – 00:05 ~ break into teams of 5 to 9 people and choose a Product Owner who will collect product vision from trainer.

00:05 – 00:20 ~ First, Product Owner reads the product vision statements for the team. After that, the team starts to place the personas on a wall with work-flow/activities/goals. Constructive discussion is the key at this stage! (Note: The goal is to identify features, modules and activities. For instance in case of a Game you might have Characters, Land-scapes and Marketplace.)

00:20 – 00:30 ~ Identify features or modules on the high level!

00:35 – 00:40 ~ Identify features or modules. (Note: At this stage try to add features/modules horizontally. You can add detailed sub-features vertically during each sprint.)

00:30 – 00:45 ~ Write user activities and workflow

00:45 – 01:05 ~ Write any user stories for each activity that users have with the product.

You can use this format:

As a  
I want to  
So that 
Note: It is recommended to put the cards horizontally rather than vertically!

01:05 – 01:25 ~ Mark Cards with Business Values (High/Med/Low) and the effort required to accomplish. You can get creative with the scaling but here are some suggestions:

01:25 – 01:45 ~ Discuss and assign Priority (MoSCoW).

01:15 – 01:30 ~ Determine Release 1. Break down the cards and create the first release (MVP)


  1. Schwaber, K. (2015). Agile project management with scrum. Redmond, Washington: Mi-crosoft.
  3. Software Engineering Institute (July 2003). Capability Maturity Model. http://www.sei.cmu.\edu
  4. Humphrey, W. (2000), Introduction to the Team Software Process. Reading, MA: SEI.
  5. Evans, I. (2004). Achieving software quality through teamwork. Retrieved from
  6. Sommerville, I. (2019). Engineering software products. First ed. Hoboken, NJ: Pearson.
  7. Ogunnaike, B. A. and Ray, W. H. (1992). Process Dynamics, Modeling and Control, Oxford University Press.
  8. Vanderjack, B. (2015). “The agile edge: managing projects effectively using agile scrum”. Business Expert Press
  9. Pichler R. (2014). “FROM PERSONAS TO USER STORIES”. Retrieved from