Understanding Agile / How to Prioritize a Sprint


CaseStudyImage

If you remember nothing else:

  • Collaborate with the Product Owner and the Development Team as the Scrum Master.
  • As the Scrum Master, Prioritization of the Sprint Backlog is a cooperative process with the development team.
  • Ensure the sprint goal is stated explicitly and is fully understood by every team member.
  • Utilize the Daily Scrum to your full advantage. This is your best chance every day to communicate efficiently across-the-board.

Contributor

Riley Barrett, CSM, CAPM – Project Manager / Software Consultant at Caprock Custom Applications.

Scrum basics

What are roles within the Scrum methodology?

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.

Key terms: sprint, definition of done, and increment?

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.

How does a Sprint fit in Scrum?

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.
Daily Scrum- A maximum of a 15-minute meeting held every day to discuss what the team worked on yesterday, what the team will work on today, and any impediments standing in their way. The only required members for this event is the development team, however it is beneficial for the Scrum Master and the Product Owner to be present.
Sprint Review- An external review with the business stakeholders and the Scrum Team to see the end result of the sprint.
Sprint Retrospective- An internal review with the Scrum Team to see “What went right?”, “What went wrong”, and “How can we make ourselves better?”. It’s very important as the Scrum Master to ensure this does not become a session of individuals blaming other team members for faults. The point of the meeting is for improvement and self reflection.

How does Sprint Planning sessions and the prioritization of Stories go hand in hand?

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.
Tasks- Written as a statement on what needs to be accomplished in the software.
User Stories- Written from first person perspective as a user on what they need to accomplish.
Epics- An epic is a huge bucket for tasks. They can be based on a feature such as: User Authentication or Push Notifications.

How to prioritize stories into the Sprint Backlog (as the Project Manager/ Scrum Master)

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.

What are the main drivers for prioritization in a sprint backlog?

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:

  • Budget / Timeline constraint on a feature or initiative
  • The businesses stakeholders / customers (Are you creating this product for internal use or external use?)
  • Bottleneck analysis (Is a bug preventing an internal department from accomplishing a crucial business process?)
  • Is there a logical way to implement the stories in order? Does creating the sign-in page first make sense before creating the user dashboard? Meet with the development team to get their professional evaluation.

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.

Is there any prioritization/ negotiation terminology I should be aware of?

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.


Back