Riley Barrett, CSM, CAPM – Project Manager / Software Consultant at Caprock Custom Applications.
The distinction of the Scrum Master, the Product Owner, and the Development Team is important. The image below describes the roles briefly.
It’s important to note that these are not necessarily “positions” that a company will have. These are roles that could be filled by various titles. For example, the Business Analyst or the Product Manager may take the role of the Product Owner. Similarly, an IT Manager or Senior Developer could take the role as the Scrum Master. These are simply roles in the scrum framework, not positions. This is largely up to the Human Resources department and/or what Senior Executives such as the CIO / CTO deem fit.
A Sprint is a timed software development initiative, typically 2-6 weeks, to accomplish an Increment of a finished piece of software. The Definition of Done is closely tied to an Increment. The Definition of Done is an agreed upon understanding by the scrum team of what the task/story needs to result in order to satisfy the requirement of it being accomplished. An Increment therefore is a particular Sprint that has the Definition of Done.
A Sprint fits in the Scrum Framework because it is a key process to achieve the work at hand. It is also one out of the five Scrum Events.Sprint- A sprint is a timed software development initiative, typically 2-6 weeks, to accomplish an Increment of a finished piece of software. Sprint Planning- The work defined to be achieved within a sprint collaboratively put together by the Scrum Team.
A successful sprint planning session will have all three groups: The Scrum Master, The Product Owner, and the Development Team. As the Scrum Master you are the facilitator and must ensure everyone gets a voice to communicate effectively what needs to be done. The Product Owner manages the Product backlog items and the goal of the entire team is to pull from this long list of items needed from the business, to help articulate a sprint for functional software. The development team will define how to achieve a sprint. The items may be phrased as “user stories” which is a first-person perspective need as a user.A template for user stories:
As a __ (user role)__ I need to be able to __(software feature)__ so that I can achieve __(business need)___.Example:
As a __Systems Administrator__ I need to be able to __ view all users in the system__ so that I can __ensure all reports are being filled out by the IT Technicians_.
After the goal has been defined you will have to estimate the work that can be achieved in this timed box 2-6 week sprint. There are several estimating techniques in the Scrum Framework. The most popular is Planning Poker.
The Product Backlog can be composed of product requirements. These requirements can be written in many different styles. They can be written in:Bugs/ Issues - Problems with the current software. This can be a “glitch” or can prevent a user from working with a particular feature.
Luckily for the Scrum Master, it’s not his/her sole responsibility to prioritize what goes into the sprint. A meeting with the Product Owner and the Development Team is crucial. The Product Owner is solely responsible for managing the Product Backlog (the big picture) while the development team works to see what they can commit to in the timebox of a sprint. Collectively the Scrum Master, Product Owner, and the Dev Team work to define a sprint goal. This will be what the developers use to define their work. If the stories in the Product Backlog don’t fit within the sprint goal then they won’t be included within that sprint.
Narrowing down the main drivers for prioritization in a sprint backlog isn’t simple. A Scrum Master must have experience with the Development Team, the Product Owner, and the Business in order to decide what the main drivers are. These could range from:
After a deep analysis of every factor only then could the team make an educated decision on what gets prioritized in the Sprint Backlog. Evaluating your team’s ability is very important. Setting realistic expectations and sometimes saying “no” to stakeholders can be a daunting task, but it’s much better than setting your team up for failure.
Utilizing terminology that business stakeholders use day in and day out is also crucial. Terms like “Cost Benefit Analysis” will resonate with them. If a feature is requested by business stakeholders and they insist on the importance of the task, having a Cost Benefit Analysis with the Scrum Team could be very beneficial if you have to tell the business stakeholder “no”.
Suppose they would like to incorporate Chart Reports on the company's management web application. If the analysis with the team determines that the undertaking will blow the budget and only provides very little business value, the Cost Benefit Analysis will show that it is a poor investment of the company's assets.
Technical terminology used by the development team is also very beneficial to know. Understanding technical concepts will allow you, as the Scrum Master, to communicate to another level that a business professional would have no clue of. An important concept to understand is Premature Optimization. Premature Optimization is when a software developer optimizes their code more efficient than necessary. In a case such as building a software system that supports only a few users, if the programmer went out of their way to accommodate the system for thousands of users then it would be a waste of company resources and would then be labelled as a Premature Optimization.