25

The phrase "backlog grooming" was officially replaced with "backlog refinement" in the Scrum Guide back in 2013. The change was largely done for: Clarity of semantics. Arguably, the word refinement expresses the idea of continuous improvement a little better than grooming. The latter denotes removing defects or straightening out. ...


22

You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues. That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes. For ...


18

In my team, if the backlog was exhausted, we always had the following to fall back on: The team can invest time and create a prioritized backlog of technical / architectural debt in your systems Work on technical debt items created using point 1 (above). Improve the automated continuous integration and continuous process. In the world of infrastructure as ...


14

That is a frustrating situation Chris. From your question, it doesn't sound like the team can't develop things in smaller pieces, but rather that they won't. I base this on the fact that it sounds like when the agile coach is there they do and just in my experience as a developer, the type of splitting you are talking about isn't usually difficult. In short, ...


9

I'm a developer working with legacy code on scrum, and let me tell you, i think they're right in their ways, because i do the same. Let me explain my case, be aware though i'm what people consider a cowboy/hacker programmer: TL.DR: breaking everything on smaller items isn't good, you're missing on patterns & interactions: you're exchanging the chance ...


8

The Product is the thing that you are building, or the service that you offer, or the need that you want to satisfy, or the vision that you have. The Product is first and foremost an idea "to do something". Only then you can you make it happen. And only then you can decide how you will make it happen. Like putting together a Scrum team, for example....


7

TL;DR The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible. By treating refinements as new work, the framework encourages ongoing collaboration between the ...


6

The only people who an accurately estimate is the people doing the work. The product owner doesn't generally code and even when they do, their job is to ask for the team to do as much as possible. The team's job is to set their limit and say no. I work with enterprise organizations and help them with longer term forecasting. The first thing is to move away ...


6

You're assuming that you know what is best for the team without being on the hook to deliver the software. I am a strong believer in agile methodologies and Scrum in particular. I fully support the iterative user story approach. With that said, there are tradeoffs to consider: If the team is either working on an existing product or is accustomed to ...


5

Quite simply, start the Sprint with what you have. However, your Product Owner (and the business) must learn the lesson that the pipeline of work is never finished. Run an ad-hoc retrospective to discuss how you ended up in a situation woth redundant cycle times. Are stories not play ready? Has the backlog been exhausted? Are no further requirements ...


5

When I first got my CSM, the course instructor specifically said that grooming was being replaced with refinement because of the child exploitation angle. I was indifferent but understood the reason for the change. For the last two years I have been working on application development projects for the Child Welfare department of my state. Grooming is ...


4

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not. Having sprint goals in advance is counterproductive. ...


4

User Stories are an Agile Practice, Independent of Kanban "User stories" are an agile practice. They are not intrinsically part of Kanban. While many practitioners do use user stories as cards or work items in a Kanban system, this is not a requirement. User stories are common in Kanban because they are often easier and faster to estimate, not because the ...


4

TL;DR Your question is phrased in a way that may lead to good answers that aren't quite on target for your specific use case. You say: [A]t the ending of a project there aren't enough story points to fill a 2 weeks sprint based on the velocity of the team. So, your question is really about how to handle the planning and Sprint length for the terminal ...


4

TLDR: It's the Product Owner (PO)'s responsibility to communicate the needs for the product to the Development Team in a format that they can use. I'll address your provided Pros for spreadsheets: All the specifications are in one place and not scattered along multiple stories. It's simple enough to make a filter in JIRA that will give you a report of ...


4

Is Task always decomposed from User Story? No. Tasks are often split from a user story, but that does not mean that a task can only exist as part of user stories and thus they always have a smaller size. Tasks can exist by themselves. You tagged the question Scrum. User stories are not a Scrum specific thing. Your Product Backlog isn't composed of user ...


4

There's a lot of grey area, but the direct answer to you question according to the Scrum Guide is no - it is not the Product Owner's responsibility to provide data mappings. https://scrumguides.org/scrum-guide.html#product-owner So... in your situation, the PO has a backlog item that says something like "As a sales exec, I want to see a graph of sales ...


3

Just like your short-term planning, the team is asked to make any long-term estimates as well. If you are using story points, they can account for unknowns and risks as well as effort, so the team should be able to make long-term estimates without all of the details.


3

The Product Owner doesn't need to care about Tasks. You should not be creating them. You should not be looking at them. You should not care about them. You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them. There is no such thing as a 'half-finished Story'. A Story ...


3

Affinity estimation is a fast estimation technique usually used for release planning. You have a product backlog full of items (or a list of the most important items) and you want to get an airplane view of how many sprints the team will need to build them all. Knowing the team's velocity and sprint length, the goal is to estimate the total number of story ...


3

Barnaby Golden's answer points to the trust associated with a product, which is very interesting and goes hand-in-hand with what Tom Graves writes in Product, service and trust: A product represents the promise of future delivery of (self)-service, via use of that product. (...) When we obtain a product, we trust that that product will deliver ...


3

I like to think of a product as having a distinct set of end users who derive value from its use. end users -> People that derive final value from the product, not people that will use the thing to make another thing (i.e. it is not a component) distinct set -> Identifyable group of people get value from it, not 'the company' or some other ambiguous entity ...


3

TL;DR Spreadsheets are great for capturing data. User stories and kanban boards are great for visualizing work or providing conversation placeholders. They can exist together. The real issue is that both can be misused. Neither spreadsheets nor index cards are "features" or "collaboration," so don't treat them that way. Instead, treat them as process tools ...


3

No, individuals doing the work decide on deadlines for the individual items in the backlog, but the product owner ultimately decides what trade-offs are needed in order to meet the deadlines required for the project. For example, if the product owner finds that launching the product in two months is absolutely needed because they want to get ahead of the ...


3

From Developer Point of View The example which you have used: 'Users Grid', with everything written in (search, filter, sort, add/edit users To achieve the above, many frameworks provide built-in tools (i.e. Yii2 Gii) and will generate the grid in a matter of minutes. Now if you want to break it out then it will require more time because the developer has to ...


3

It does make sense to have some differentiation, however, the proposed differentiations don't make much sense to me. First, it seems like you're using "ops" and "DevOps" interchangeably when they aren't. Operations is a type of work. Operations, or ops, means different things to different organizations. I see it as the set of work needed ...


2

Short answer is: yes. Backlogs are assumed to be emergent and are expected to change and be re-prioritized often.


2

There is normally no formal process for handling change requests in Scrum because changes are expected and encouraged as the project is in progress. A change would normally be handled like any other feature request. It would be added into the Product Backlog and prioritized with other features and capabilities.


2

TL;DR This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team ...


2

What you have here is a disagreement. You prefer doing things one way, the technical team prefers their way. So the way to fix this is to ask WHY?. And not just why they prefer their way, but also why you prefer your way. Maybe they are set in their ways, and you are set in yours. Maybe they don't understand all this Agile thing and don't see the point. ...


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