Unveiling The Office Green’s Virtual Verde Project – Part 2

Having established the theoretical foundations of Agile project management and its relevance to the Virtual Verde project, let’s take a closer look at how these principles were implemented in practice using Scrum as a framework. Specifically, we will look at how the project team adopted an Agile mindset and used Scrum as a project management framework to manage the project effectively. We will also explore how my team and I created a Product Backlog, Sprint Plans, and Sprint Backlogs, and how we recapped Sprint Retrospectives to continuously improve the project’s performance.

Creating a Product Backlog

1 – Identifying user stories

Now, as a project manager, I’m overseeing the development and launch of Virtual Verde, Office Green’s new product line. Virtual Verde’s mission is to make working from home more enjoyable by offering desk plants for home office use. New customers recently received the first batch of plants. With the increasing trend of remote work, Office Green saw an opportunity to expand its product line by offering plants that not only improve air quality and overall well-being but also add a touch of nature to home offices.

As a next step, my team had planned to introduce new product offerings to the Virtual Verde catalog—starting with Bonsai trees. However, a customer survey discovered that 70% of the new customers had difficulty caring for their plants. Many of the plants wilted and died within a month. This information inspired the team to develop new offerings and companion products to help new owners care for their plants.

From the survey, Office Green learned that they can create value for their customers by making it easy to:

Find out which plants are easiest to care for
Access care instructions easily
Have the right tools to care for their plants
Remember when to water their plants
Get expert help and advice quickly
Have a hassle-free way to return their orders

I’ll work with my team to create user stories that will help them build solutions to address these customers’ needs and add them to the product backlog along with the product owner.

In Scrum, the product backlog items are usually written in user story format and estimated in story points (see adding estimates below) by the development team which is responsible for delivering the product increment at the end of each sprint.

A user story is a brief, simple description of a feature or functionality from the perspective of a user or customer. It typically follows a simple format: “As a <user role>, I want to <this action>, so that I can <get this value (goal or benefit)>”. User stories are used in Agile development to capture customer requirements and prioritize development efforts based on business value. They are often used to populate the product backlog, which is a list of all the features, requirements, and enhancements that need to be developed for the product. The product backlog is constantly evolving and prioritized based on customer feedback and changing business needs.

My team has already added Bonsai trees user stories to the Backlog, but the new plant care stories have now become the top priority. In general, the Product Owner leads in prioritizing the Backlog and addressing new concerns. Anyone can work on user stories, but the Development Team typically gives feedback on them.

2 – Adding estimates to user stories

It’s time to add estimates to user stories to the Virtual Verde Product Backlog in order to capture how much effort each user story will take to complete. These estimations help the Product Owner assess the workload captured in the Backlog, which helps them prioritize tasks.

Effort estimation is an important aspect of Agile project management. It helps the team to understand the complexity and duration of work for each user story. The estimation is usually done by the development team, who will break down each user story into smaller tasks and estimate the time needed to complete each task. The team can use various techniques to estimate the effort required for each user story. These estimates are then used to prioritize user stories in the product backlog and to plan sprints. The team should keep in mind that effort estimates are not set in stone and should be updated as the project progresses and new information becomes available.

Now, Along with the Product Owner and the team, I’ve created user stories and acceptance criteria for the Virtual Verde Product Backlog. Now I need to add effort estimations to each user story, which will help the team understand the amount of effort each task will take to complete. Once we have our estimations, the Product Owner can make any necessary adjustments to item priority in the Product Backlog. This information will help my team plan the upcoming Sprint.

The Product Owner has already added a specific value for each user story in the Product Backlog. In this project, a value represents how valuable the final deliverable is to the user role or customer. These value points are designated by dollar signs ($ = 1 value point, $$ = 2 value points, etc.).

I’ll work with the Development Team to determine relative effort estimations for each Backlog item. Relative effort estimation isn’t just how much effort an item should take to complete. Instead, the Development Team evaluates the amount of effort each item takes compared to other items in the Product Backlog. In other words, relative estimation is a technique that involves comparing the effort required to complete a task to the effort required to complete another task instead of trying to determine exactly how long the task will take. The estimation is done by assigning a relative value or size to each backlog item, rather than using traditional units of time such as hours, days, or weeks.

We can use a number of different methods to estimate effort, but my team has opted to use story points. When estimating user stories using story points, teams usually use the Fibonacci sequence, which is a mathematical sequence where each number is the sum of the two preceding ones. The sequence goes as follows: 1, 2, 3, 5, 8, 13, 21, and so on. The idea behind using the Fibonacci sequence is that it allows the team to consider the complexity of a user story, rather than just the amount of time it will take to complete. The numbers in the sequence represent a range of effort required to complete a task, with higher numbers indicating more complexity or uncertainty.

For example, an item with an effort estimation of “1” should take little effort to complete, while an item estimated at “13” or “21” will take much more effort. There is no prescribed formula for determining story points. Rather, teams should work together to compare task estimations to one another. By using a non-linear sequence, story points provide more accuracy and specificity than simply using hours or days to estimate effort. It also prevents the team from overthinking small tasks or underestimating larger tasks.

3 – Completed Product Backlog with user stories and estimates

Previously, I entered new plant care user stories into the Product Backlog that already contained Bonsai Trees epic. Basically, an epic is a large user story that cannot be delivered in a single sprint and needs to be broken down into smaller, more manageable user stories.

Before I add effort estimates to the plant care initiatives epic, I reviewed the estimates for the Bonsai Trees epic. I used these numbers as a baseline to determine the relative estimations for the Plant Care Initiatives epic. Then, I considered how much effort the acceptance criteria for the “Plant Care Initiatives” compared to those in the “Bonsai Trees” epic, so I can define a Story Point value that makes sense relative to the “Bonsai Trees” estimations.

For example, the user story “As a Bonsai tree owner, I want to have the right tools to care for my tree so I can shape and style it properly” has an effort estimation of 13. I had to think about whether the “Plant Care Initiatives” user stories require more, less, or about the same amount of effort to make my estimations.

Overall, the completed Product Backlog comprises six user stories, all of which fall under the “Plant Care Initiatives” epic. Each user story is written in the “As a <user role>, I want <this action>, so that I can <get this value>” format and adheres to the I.N.V.E.S.T. framework, which ensures that each story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. Additionally, each story has two pieces of acceptance criteria, which represent the tasks that the Scrum Team must complete to consider the user story done. The acceptance criteria are actionable and help establish a Definition of Done. Finally, each story has an effort estimation in Story Points, which range from 1 to 21.

This document encompasses the Product Backlog with user stories and their effort estimates for the Virtual Verde Project: Product Backlog.

Creating a Sprint Plan and Sprint Backlog

Now that I’ve added epics, user stories, acceptance criteria, and estimations to my Product Backlog, it’s time to plan our first Virtual Verde Sprint. I met with the Product Owner and my team to decide which items from the Product Backlog to address in our first Sprint.

During our meeting, my team and I answered the following questions:

Who is available? All team members are available for the Sprint.
What is the team’s points capacity? The team can typically complete 60 Story Points per three-week Sprint. Team points capacity (also known as velocity) refers to the amount of work, measured in story points, that a team can complete within a single sprint.
How long is the Sprint? The team decides that this Sprint will take three weeks.
What can and should the team accomplish in this upcoming Sprint? What is the ultimate Sprint goal? The Sprint Backlog can include stories from both epics, but the Product Owner has asked you to prioritize the Plant Care Initiatives epic first. If the team has enough capacity left over, they can start work on the Bonsai Trees epic.

To plan the upcoming Sprint for the Virtual Verde project, I will assign items from the Product Backlog to the Sprint Backlog while ensuring that the total effort estimation (in Story Points) of the assigned items aligns with my team’s points capacity for a three-week Sprint. Both the Product Backlog and Sprint Backlog are included in a single spreadsheet, with each in its respective tab.

In the Sprints section of my Sprint Backlog spreadsheet, I have added the total number of Story Points that my team expects to complete in the upcoming Sprint under the Current Sprint column.

To maximize value and velocity without exceeding the team’s points capacity, I will sort the items in the Product Backlog by the Value column and assign the highest value items to the “Current Sprint” tab until the number of Story Points assigned matches the team’s expected capacity, starting with the stories in the Plant Care Initiatives epic. If the number of assigned Story Points exceeds 60, I will skip that item and assign the next item that fits within the remaining capacity. Any remaining items are assigned to the next Sprint in the Product Backlog tab of the spreadsheet.

Using Google Sheets, the Backlog items assigned to the Current Sprint automatically populate in the Sprint Backlog tab. I will ensure that the total number of assigned Story Points matches the capacity for the Current Sprint. If necessary, I will reassign the Product Backlog items accordingly. The Points Assigned and Value Attributed columns display the total number of assigned Story Points and value, respectively.

It’s worth noting that there is more than one right way to build a Backlog. There could be project needs or dependencies that cause the Product Owner to make adjustments. The project’s team will continue to iterate and complete Sprint Planning throughout the life cycle of the project.

Overall, the completed Sprint Backlog spreadsheet includes Backlog items allocated to the Current Sprint, any remaining Backlog items are assigned to the Next Sprint, the total Story Points assigned to the Current Sprint match the team’s capacity, and the Current Sprint’s value exceeds that of the Next Sprint.

This document displays the Sprint Backlog for the Virtual Verde project, outlining the team’s plan for the upcoming sprint: Sprint Backlog.

Recapping a Sprint Retrospective

The Virtual Verde team has completed the first Sprint based on the Backlog we created earlier. The team also gathered for a Sprint Retrospective to go over what worked well during the Sprint, and what they want to change for the future. My team reviewed each item from the Sprint, and discussed how the work went and how the team performed.

After the Sprint Retrospective meeting, I’ll reflect on the team’s accomplishments and identify areas for improvement using the notes from the whiteboard that the team created during the discussion. Then, I will send an email to the Scrum Team recapping the key takeaways and action items from the retrospective.

During the retrospective, the team used a +/Δ format, listing what went well under the + heading and roadblocks or things to change under the Δ heading (Delta is the mathematical symbol for change). I’ll review the notes and create a list of 5-10 key takeaways, which could cover topics such as team performance, task completion, workflow, communication, or any other issues that were discussed. For example, if the team noted that they did not fully understand the scope of a particular task, the takeaway might be to review the estimating process to ensure that the full scope is accounted for.

Finally, I will compose a recap email summarizing the retrospective meeting and highlighting the key takeaways and next steps.

These documents include the whiteboard notes from the Sprint Retrospective of the Virtual Verde along with the recap email to the Scrum Team: Sprint Retrospective Whiteboard + Sprint Retrospective Email.

Making changes to the release plan

A release plan is a high-level view of the timeline for delivering valuable increments of the product, outlining the order in which features or user stories will be developed and released based on their priority and potential impact on the product’s value. The release plan serves as a roadmap for the development team, stakeholders, and customers, providing visibility into the product’s expected delivery dates, features, and functionalities.

Changes and updates can significantly impact the release plan. They can arise at any time, and Scrum Team must know how to determine the scope of the impact and solve problems quickly. For example, if a new feature is added to the product, it may require additional development time, which could delay the release of other features. Similarly, if there are issues with the quality of the product or unexpected obstacles during development, the release date may need to be pushed back. These changes may also affect the priorities of the features and their order of implementation, which could alter the release plan.

To manage changes and updates to the release plan effectively, the Scrum Team must continually monitor the progress of the project and adjust the plan accordingly. The Product Owner must work with the development team to identify any potential roadblocks or changes that could impact the release plan, and then communicate those changes to stakeholders as early as possible. This allows the Scrum Team to adapt to new information and ensure that the product is delivered on time and with the expected quality.

Now, at Office Green, my Scrum Team and I have successfully conducted a test run, created a Sprint Plan, and addressed project issues for the first release of Virtual Verde. As we approach the second and third releases, I have received three emails from the Content Manager and Vendor Manager that may require changes to the release plan. I’ll go over the plan and make note of the timeline and the objectives we want to achieve for each release. Next, I’ll review the emails and determine if they will affect the timeline or content of our release plan.

For each email, I’ll address the following questions:

Does the update require action from my team? If so, what are some possible options to address the update?
Do we need to consult with anyone to make a decision? If so, who?
Do we require additional information to help reach a decision? If so, what do we need to know?

If I determine that changes to the release plan are necessary, I’ll write an email to the Scrum Team informing them about the update and describing a course of action. If not, we’ll proceed without making any changes. The email will provide clear guidance on any adjustments the team needs to make.

These documents include the Virtual Verde Release Plan and emails about necessary updates to the plan: Release Plan + Release Plan Emails.

Featured Image by Freepik. Used for display purposes.
Last updated: April 30th, 2023.