As a one-man Scrum team, a lot of the framework provided with Scrum and Agile can be hard to apply. For example, how do I define a sprint goal for my team when I am the team, or how do I determine how much work the team is capable of when again, I’m the team.

Shouldn’t being a single person scrum team make these easier to accomplish? I mean it would stand to reason yes as I don’t have to confer with others on a sprint goal and who better to know my own capabilities than myself. The issues arise in a few places.

The most important being, as someone who is new to scrum how will I know I’m setting a realistic or achievable sprint goal. How will I know I’ve chosen the right goal for that given part of development?

Another given issue is with being the one who sets the goal and the timeframe who’s going to keep my honest and working as hard as I can without burning out? I can push myself incredibly hard and burn out after one sprint or I could accomplish almost nothing because I just didn’t feel like it and didn’t have to answer to anyone.

Thankfully, the first issue can be solved by researching sprint planning. In “Creating a Sprint Backlog: Your Guide To Scrum Project Management” by Dana Brown, she details how to create a sprint goal, how to create a sprint backlog, and how to prioritize tasks.

She highlights the first two steps of sprint planning as setting a sprint goal and identifying important product backlog items. Thankfully this is where my first issue is solved. As someone inexperienced to scrum, I would start at step two which is identifying the important product backlog items and using those to create a sprint goal. This way my sprint goal is relevant and knocks off the items highest on the priority list.

From there I can breakdown my product backlog items into smaller tasks and add them to the spring backlog. Finally organizing these tasks based of their priority and prerequisite tasks.

So, my first issue has been resolved, I now have a method of creating a sprint goal relevant to what’s highest priority. As for my second issue, unfortunately I don’t think I’m going to find an answer to that one online. It’s going to be trial and error as well as being completely honest with myself on whether the workload is too much or too little. Ultimately, it’s going to come down to how disciplined I can be.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

With an honors project coming up for one of my courses I was going to have to learn how to become a single person Scrum team. With the average scrum team being seven to ten people, I knew it was going to be both a strange and difficult task.

I knew my first order of business would be to create a product backlog as I am the product owner (among many other things being the only member of the team). Diving in headfirst, I knew what a product backlog was but not how to set up an effective one.

Thankfully, “A guide on Scrum product backlog” by Brianna Hansen was the perfect blog to stumble across. She eloquently states what a product backlog is, why one should be maintained throughout a project, and how to create a product backlog geared towards success. As an added bonus the end of the blog even provides a platform to create and maintain a product backlog.

As I previously stated, I’ve known what a product backlog is. It’s everything that needs to be done for a product, including maintaining it. As much as a product backlog is a to-do list, one way to increase success is to not overload it. Keep it simple but effective. No one on the Scrum team (in this case me) wants to scroll through a product backlog for hours.

Time management is crucial for a product backlog. Certain items contained in the backlog are going to be more time consuming than others so considering this when putting product backlog items into the sprint backlog is very important to sprint success.

Defining the product vision is one of the major points she gives for maintaining a successful product backlog. This usually involves the whole team getting involved to make sure the vision for the product is shared. While in my case I may be the only member Hansen does give some very important questions for me to ask myself when planning my product and adding items to the backlog.

• “What problem does the product solve?”
• “Who are the target users or customers?”
• “What unique value does the product offer?”

Taking these questions into consideration will help to guide me through this project and help to increase my chances of success.

Finding this blog was incredibly helpful for taking my first steps into trying Scrum firsthand and I intend to use what I learned as I navigate my honors project.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.