Using Shared Resources In Daily Sprints - How Is This Possible In Scrum?

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

The daily sprints represent the main area of activity for an Agile team. During the sprint, the team develops a small portion of the actual product to be delivered to the stakeholders and project owners. This can include the designing aspect, actual development of the user story, testing and debugging, and even documentation to accompany the developed product feature. During the sprint planning meeting, the product owner selects some of the high value product backlog items and transfers them to the sprint backlog in the form of user stories for development purposes. The focus then shifts from the product owner to the development team.

One interesting concept used in scrum is sharing of resources across multiple sprints. Usually the resources in terms of developers or programmers, i.e. the development team members, are allotted to develop sprint backlog items in a sprint belong to a specific project. However, at times, the management may own multiple projects, and they might be executed simultaneously. Typically, in such cases, two or more projects are implemented simultaneously, with each scrum project having its own ...
... product master and individual sprints. To minimize upon the production cost, the management often shares resources across multiple projects. A developer works in not one but multiple sprints simultaneously. The question is how is this possible? Scrum methodology advocates the team members should put in 100% of their efforts while a sprint is underway. When a team member is allotted for a project, how can the same person put in cent percent while working with multiple sprints?

Shared resources in daily sprints
Scrum is all about adapting to changes and delivering shippable items at the end of sprints. There are a number of ways how product owners can share resources and save upon the operational costs, and still deliver shippable items at the end of daily sprints. The management may decide to share the resources depending upon the project requirements and the availability of resources.

Scenario one – Multiple projects share common resource and user story
Suppose the management starts with a project “A” which is aimed at developing a particular product over a certain duration. Based upon the requirements stated by the stakeholders, the product owner creates the product backlog for that particular project and writes down the user stories specific to the project along with the acceptance criteria. Simultaneously, another project “B” is also initiated by the stakeholders to develop a totally different product. The management appoints another product owner to handle project “B”. When the product backlog items are prepared for the second project, it is found that some of the features or functionalities are shared by both the projects. In such cases, it does not make sense to waste resources and working hours in developing the same functionality again for the second project. For scrum, the development is carried out in the daily sprints. It is essential to have two distinct sprints to develop user stories for both the projects. Since the development activity is to be shared in both the projects, a certain portion of the sprint belonging to project “A” is shared, or overlapped, with the sprint belonging to project “B”. The shared resource develops the task for one particular project but it is shared by the sprint belonging to other project. The velocity is reflected in the project burn down charts belonging to both the projects.

Scenario two – Multiple projects share common resource developing distinct user stories
Sometimes the stakeholders are required to develop more than one product at a time and start individual scrum projects for them. The project owner may appoint individual product owners and scrum masters to executing the scrum projects, but may decide to share some of the resources in both the projects. In such a scenario, the product owners may plan individual sprints for both the projects. Each project may maintain its own development activity and project estimation, but as far as sprints are concerned, the shared resource may develop user stories belonging to both the projects. Typically, the shared resource might work upon a few user stories belonging to the first project, and subsequently start working upon the user stories belonging to the second project. The resource does not put in 100% for any single project, but rather the product owners decide how much time the resource should spend for a particular project, and how many story points need to be developed for both the projects by the same person.