Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
19

Does a product backlog item maps to a user story? Are they the same? Not necessarily, but in general, they do. Like your scrum master said, other things can be product backlog items, too. However, it depends on how your SCRUM works. Some teams have a separate bug backlog which is taken into consideration for sprints as well, while others keep such things in ...


15

I'm no expert but I'd say you can only have one backlog per team. The team needs to decide which issues are urgent and which ones can be postponed. If you separate the issues into separate types of stacks you go against the core idea that is at the heart of scrum, which is that there is a pool of issues and each sprint the team works on the most urgent of ...


15

if you can't estimate - and in this scenario it sounds like there really is no way to know in advance how long any particular part of the process will take - then the next-best option is to time-box the effort: how much time you're willing to spend on it, whether you get anywhere or not once you get into it, you may have a better idea of how to estimate the ...


13

The usual approach is that anyone can add stories to the backlog. The product owner prioritizes them and the team estimates them. Story quality issues generally get taken care of one way or another in planning meetings or retrospectives. That means the product owner isn't a bottleneck as long as you're satisfied with the priorities he's assigning. ...


10

I will talk about a few points which, hopefully, will help you find your way: "SCRUM" is about being agile. Common sense is required. If the change is a few minutes change, I don't think you need a backlog for it. If it's more than 2 hours, I think you should give it a second thought. Not everything that is an "easy-win" should be done. In SCRUM you work by ...


10

TL;DR Scrum does not mandate the use of user stories; they are simply a useful agile practice. While the Product Owner could certainly use technical specifications instead of user stories to build the Product Backlog, most of your other process problems stem from a failure to embrace effective Scrum and agile practices. Various Problems with Your Process ...


9

I don't think the problem here is Scrum as such, I think the problem is that there isn't a clearly defined project deliverable and (I've experienced this many times) no clear direction. I think your technical tasks are fine, possibly on the large side but measurable and definable so absolutely fine for a story. Research tasks are a huge red flag for me in ...


9

I'd like to add my voice to those who recommend one backlog per product. Creating another backlog is a rational response, but is really just avoiding the core issue: Why won't the Product Owner prioritise technical items over feature items? You should focus on solving this rather than working around it. You could use the 5 Whys technique, for example, to ...


9

The confusion is due to ambiguous language. The Sprint Backlog has two levels of detail. First, it is a list of Items (User Stories) that the Team has committed to deliver. Second, it is all the TASKS that the team intends to do in order to deliver each of those stories. So when people talk about the Sprint Backlog, they should really be clear about what ...


9

First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical). But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the ...


7

My personal perspective from having worked in agile for a few years, is that you really shouldn't fear a large backlog (to a point). If you are writing self-contained user stories, each of which is effectively complete in and of itself, then you really only need order them by priority and things shouldn't get more "complex" as new stories are added to the ...


6

Silver Stories made by Silver Stripe Software seems to fit the requirements of this question. (They reached out to me after I complained online about my problems with their product and got the problem resolved.) I've been able to use the story-mapping technique with this tool and create a small sample story map: I've been also able to take stories ...


6

What you're referring to is commonly called 'technical debt'. It can sometimes be difficult to see how technical debt work fits into the scrum process, in the same way that defects can. What you are proposing is similar to suggesting that there be a separate 'defect backlog' as well, splitting the backlog into 3. Personally, I would not advocate splitting ...


6

I'm currently 2/3rd of the way through Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise and I would highly recommend that book as it covers a lot of the topics issues involved in scaling out agile process to more than one team and maintaining backlogs for enterprise-level products (i.e. those that might span ...


6

A more "vertical" approach is the common guidance on splitting stories. What it reinforces is: A multi-functional team capable of working on the whole product Building a dirt road and then adding features to it Keeping the portion of an added feature useful to the end user However, what I don't have a good answer for is that typically there is some prep ...


5

If you read a bit farther in the Scrum Guide page you linked, it also says: The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.


5

The product owner knows what is important, and prioritizes the backlog. The team knows what is possible, and can estimate backlog items. Together, they can create a sprint goal that is both relevant and achievable. This is part of the Sprint Planning Meeting. In the simplest case, this simply involves estimating the most important items in the product ...


4

Try to go Lean here. If keeping the DONE stories past the completion of a given sprint is taking up space on the wall and not adding any value, it's a waste and it's time to make a process improvement. I'd hesitate to just throw them away until you are sure you don't need them, but I'd consider archiving them, either physically or electronically. That way, ...


4

I agree with Onno in that there should be only one single backlog per project. Otherwise, the team is basically taking in their own hands some decisions which rightfully belong to the product owner. Even "purely technical" items must have some practical value for users (and therefore for the product owner) to be eligible for the sprint backlog. It is your ...


4

Scrum says that you'd better have a deliverable product to your customer. However, the point here is that, it doesn't specify the deliverable product and the customer. In other words, in your specific case, you might define your deliverable product as code improvements, platform changes, rewrites and redesigns, etc., and consider your technical manager to ...


4

Incredibly simple: It's always 3 points. (or pick a different constant). This is the approach we took at our last job and I think it worked out relatively well. The idea is that you have a backlog full of actual stories and one of them happens to be an integration story with a device you know nothing about. If someone asked me to size that story(actual ...


4

A backlog, by definition, is "an accumulation or buildup, especially of unfilled orders or unfinished work". A Product Backlog is only the work that is known to be remaining on the product, just like the Sprint Backlog is only the work that is remaining to be completed in the Sprint. The Scrum Guide concurs for both the Product Backlog: The Product ...


4

Based on your description, the common library appears to be a collection of business functionality and utilities common to many of your projects. Regressions caused by one product's modifications may not be immediately visible in the other products. Some core recommendations are: Versioning As you mention, the library is pretty stable. Versioning this ...


4

I don't agree that the stories you presented are sliced horizontally. With horizontal slicing, you see stories that are targeted at different disciplines within the team or stories that don't offer any functionality to the user until the complete feature is done. If you have vertically sliced stories, then each story offers something to the user, even if ...


4

Here's the trouble I have with the user stories you list: it seems like there is an exact implementation in mind and someone is trying to write user stories around that. That isn't the point or benefit of user stories. User stories should be written with the user need in mind. Something like: As a meeting organizer, I'd like to be able to pick a date off ...


4

This is a bit confusing, but in the Scrum Guide, there are two key responsibilities split between the Dev Team and Product Owner: 1) Product Owner owns the priority in the backlog. 2) Only the team can say how much work comes into the Sprint. From a strictly Scrum Guide standpoint, this means that the conversation must be collaborative between in the ...


4

The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide. It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one ...


3

You should keep the small stories in the main backlog. I face similar issues to what you are describing, although I am not using scrum. I see that you face challenges of prioritization and efficiency. It sounds like under your "old way", anyone was implicitly empowered to make their task the current "top priority" if they visited a developer's office. ...


3

Programming frameworks like Agile and SCRUM are designed to apply discipline and structure to development. However, discipline and structure seem to be the antonyms of fun and creativity. Typically, you need to work harder to establish and maintain discipline. It is very difficult to find a balance between the these opposing concepts. Therefore, ...


Only top voted, non community-wiki answers of a minimum length are eligible