Who Are ‘Developers’ In Scrum?

‘Developers’ are one of the 3 accountabilities in the Scrum Framework as defined in Scrum Guide 2020. They are committed to creating usable Increment for each Sprint. Don’t get confused with the term ‘Developers’ means coders only. Anyone who is involved in product development activities such as Coding, Architecture, Analysis, Testing, UX, UI, Front End, Back End, Deployment; is a Developer.

Scrum Team has 3 accountabilities

Developers are accountable for Sprint Backlog, one of the artefacts in the Scrum Framework. Sprint Backlog reflects their plan to meet the Sprint Backlog. They are responsible for the ‘How’ of the product development.

While the Product Owner is responsible for the Value, Developers are responsible for the Quality. They make sure that Increment has quality as defined in the Definition of Done.

Developers are self-managing i.e. nobody tells them how to turn Product Backlog Items into an Increment. Others can suggest or Developers may consult others but the final decision is with the Developers. To achieve that, they hold each other accountable as professionals.

Developers are also responsible for sizing Product Backlog items. The Product Owner can assist this activity by helping them understand the Product Backlog Items.

Developers are also responsible for sizing Product Backlog items. The Product Owner can assist this activity by helping them understand the Product Backlog Items.

Developers & Scrum Events

Scrum Framework
Scrum Framework by Scrum.org
  1. Sprint Planning

Developers know best how to convert Product Backlog items into an Increment while adhering to the Definition of Done. This will help in defining how much work they can do in a Sprint. Together with the other Scrum Team members, they help in crafting a Sprint Goal.

Once Sprint Goal is crafted, Developers with assistance from the Product Owner, select the Product Backlog items to meet this Sprint Goal. They also consider their past performance and capacity in forecasting the work they can complete.

The next step for Developers is to create a plan to convert these Product Backlog items into an Increment. Generally, they decompose Product Backlog items into smaller tasks. However, this is not mandatory, but a good practice. This decomposition helps Developers’ shared understanding and they are more informed about the size and complexity of the work. This information can lead to adding/removing Product Backlog Items from the Sprint Backlog.

Creating Sprint Backlog is Developers accountability. Product Owner can’t force them how much work Developers can pull from the Product Backlog. However, to maximise the value high level of collaboration is required.

This image has an empty alt attribute; its file name is image-2.png
We learn more about this in Scrum.org PSM/PSPO Class.

2. Daily Scrum

Daily Scrum is for Developers only. Other Scrum Team members may join but it is the Developers’ meeting. During this Developers inspect their progress towards the Sprint Goal and create a plan for the next 24 hours. How they do that is entirely up to Developers. However, if the Developers are new to the Scrum framework or facing any issues, then they can request Scrum Master to facilitate/teach/coach.

The outcome of the Daily Scrum is an updated Sprint Backlog.

This meeting enables better communication, collaboration and alignment among Developers. It also enables quick decision meetings.

Myth: Daily Scrum is a problem solving or status update meeting for Developers.

Fact: It is a collaborative planning session for Developers to create their plan for the next 24 hours to meet the Sprint Goal.

3. Sprint Review

In my experience, Sprint Review is the most neglected and misunderstood Scrum event. For Developers, this could be of the best events to build the context and get an opportunity to know the ‘Why’ better.

Many Developers are not very close to stakeholders and customers. This gap sometimes keeps them away from ‘why they are building something’, ‘what customers’ problem we are trying to solve’, ‘what is the value’, ‘what is the urgency to delivering certain items’.

  • First, the Product Owner should identify the right stakeholders ( whose feedback and information can maximize the value)
  • To build the context and alignment, the Product Owner should start the event with the Product Vision and the Product Goal. This will also act as a reminder of the big picture to everyone: the Scrum Team as well as stakeholders.
    • Tip: This should not be limited to the Product Owner. Developers can try as well. This generally boost confidence and get them closer the stakeholders.
  • Scrum Team share the Sprint Goal and connect how this Sprint Goal is a stepping stone towards the Product Goal.
  • Scrum Team (better if Developers) shares the Done Increment with the stakeholders and stakeholders provides feedback.
  • The feedback is really crucial for the Developers as and it helps them understand quality desired by stakeholders
  • Product Owner also seek for any information which he/she might not be aware of and can influence the future of the Product. This information may lead to changes in the Product Backlog. This information helps build the context for the Developers.
  • Product Owner also shares the progress towards the Product Goal and what could be delivered next. This brings alignment and transparency for stakeholders as well other members of the Scrum Team including Developers.

4. Sprint Retrospective

Developers attend Sprint Retrospective as a Scrum Team member and equally participates in inspecting the Sprint in terms of people, behaviours, tools, processes, and quality.

  • Few improvement actions that can really help a Developers are
    • Right level of details (description, estimate, value, users/customers, size) in the Product Backlog items
    • Relationship/communication between the Product Owner and the other Scrum Team members
    • Frequency/amount of Product Backlog refinement
    • Definition of Done
    • Do we need to add/remove any internal process to improve quality. For example: Code Reviews, Pair Programming, Automation Testing, Test Driven Development ( TDD) or Behaviour Driven Development (BDD).
    • How are we managing conflicts ?
    • Are we acting as a Team or bunch of individuals who are meeting their own goals?