Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Guilherme Rebane
1,119 PointsSome kind of development requirement, as "Register a Domain Name" Could be in Product Backlog? thanks
ex. Need to Create a domain name. Does it make sense to go to product backlog?
6 Answers
Matt Anthes-Washburn
Treehouse Guest TeacherYes, technical items are perfectly valid items for the product backlog. Generally, I define an item as a technical item when the direct value is not to the user, but rather to the development team. The trick for me, as a Product Owner, is to figure out the priority of those items. For a user story, the value is user facing, so I can use my understanding of the user (or I can talk to users) to gauge the value. For technical items, like refactoring code or developing automated tests, I often need help from the technical team to figure out the value of that item relative to other work.
A really nice strategy for giving technical items their due is to reserve a little capacity for technical items in each sprint, say around 10%. That means that as the team starts to get near the end of their capacity in Sprint Planning, I ask them to step back for a minute, look at technical backlog items, and nominate ones they'd like to bring in because of their technical value to development efforts. This also helps to reduce technical debt over time. If you do a little bit of technical work in each sprint, it helps to avoid the situation where the technical debt becomes so overwhelming that it slows the team to a halt.
What do you think? Does that make sense?
Ryan Ruscett
23,309 PointsYes - The backlog is where anything that needs thought, but not during the current sprint resides. It can hold anything that is not defined all the way or not as important as the current stories / tasks outlined by product management or product owner.
I would define this as an epic. For it's a chunk of work that needs to be thought about, as well as broken down into individuals tasks and all tasks are associated with some sort of story outlined from the brainstorming of the epic. Make sense? lol The first few sentences are the best.
Although, there are guidlines to a back log. There is nothing really set in stone that says no you can't or yes you can. It's just a way to store things and not forget about them when the need arises and or the work load is lower and minor changes or fixes can be made.
Hope this helps.
Pavlo Kochubei
15,009 Points@mattaw Thanks for you answer. Also, in one of the videos you mentioned that each Backlog item has conditions of acceptance. Is it related to Sprint goal or final product? Could you give an example of those? Thanks again.
Matt Anthes-Washburn
Treehouse Guest TeacherHi Pavlo,
The Conditions of Acceptance relate directly to a single User Story. They compose a simple list of the requirements that need to be met to satisfy the story. Here are a few questions that your team can ask when constructing Conditions of Acceptance:
- How will I know this story has been satisfied?
- What tests can I do on working software that will confirm that the story is ready?
Let's say that the User Story is something like:
As a student with a question,
I need access to the forum
so that I can see if someone else has asked the question or ask it myself.
The Conditions of Acceptance might include:
- I can navigate to the forum from the course.
- I can easily see the navigation and understand its purpose (usability testing).
- When I arrive at the forum, I see questions asked by others.
Not only do the Conditions of Acceptance make the meaning of the User Story clearer, but it is easy to test whether the story has been satisfied. When the team thinks they are "Done" with a story, they will review the Conditions of Acceptance along with their shared definition of "Done" to check whether the story is ready for the Product Owner to accept.
Does that help?
Pavlo Kochubei
15,009 PointsThanks for the reply, @mattaw. This really helps.
Then, what about the Sprit Goals with relation to the Sprint Backlog and how it's populated from the Product Backlog.
Can the result of sprint planning look like this?
For example.
User story: <br/>
As a potential/existing student </br> I need to signup/login flawlessly </br> so that I can access the courses
<br/> Conditions of Acceptance:
- As a new user I can easily register on the site
- I can do it manually or via 3rd party API
- As an existing user I can easily login and access my courses <br/> Sprint Goal: Working Sign In/Sign Up process.
Sprint Backlog:
- Database schema ( required user information)
- Mock-ups of Registration forms
- HTML/CSS Templates of Registration forms
- Javascript/jQuery interactions
- Post userdata to Database
I might have simplified some things, but I'm just trying to understand the process better. I felt like there were not so many examples in the courses videos.
Thanks again, Matt. Really appreciate your help here.
Pavlo Kochubei
15,009 PointsI guess, it's an art to organize the process:)
Matt Anthes-Washburn
Treehouse Guest TeacherYes, it takes practice to maintain the backlog and to refine user stories. You're on the right track!
Matt Anthes-Washburn
Treehouse Guest TeacherYes, it takes practice to maintain the backlog and to refine user stories. You're on the right track!