Hot answers tagged

10

I want to supply a bit of a purist answer not because it is necessarily more "correct" than some of the others, but to give a different perspective. In many modern implementations of Scrum, the next 5 sprints are assumed. We plan very large projects into a set of sprints. This does deliver some value, but it misses part of the core point of Scrum: ...


6

I'm not convinced that what you describe fits the notion of "large, non-reducible tasks". So far, I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint. Fixing a critical bug that is hard to pin down and resolve The steps here are pretty straightforward: Get reproduction steps. ...


4

The point of the Sprint is not to finish work in the Sprint but to accomplish something within the Sprint. There is a difference between the team having an output and an outcome. Obviously, in order to accomplish some outcome you have to finish the work selected for that outcome. If you don't finish the work in a sprint then it means you haven't reached your ...


2

The idea is to break larger PBIs into items small enough to accomplish within a sprint. There are multiple advantages of doing that. From the customer's point of view it means they get something faster and they have evidence of the team's ability to deliver value on a regular basis, regardless of the size and complexity of the work. Fixed iterations also ...


1

It seems like this question is based on the misconception that decomposing a large feature into smaller units of work is a form of big design up-front. It's not. Big design up-front is designing the whole system, or at least large parts of a system, before starting any implementation and integration happens. Although decomposition is a design activity, it's ...


1

Scrum and its associated techniques don't eliminate the need for long-term planning but they can help make your planning and estimation tasks easier. If you deliver in fixed-length increments then your estimation only needs to be good enough to estimate the number of sprints a big ticket item will take rather than the number of days effort or duration. ...


1

Great question! Kanban works best when all tasks are a very similar size. Your team's velocity is simply the rate at which they complete tickets. This makes predicting effort reasonably easy. Which ticket size to use? From experience, 3-5 days works quite well. If a ticket is larger than 5 days, we split into smaller tickets. If a ticket is only 1-2 days, we ...


1

"Upstairs, Downstairs™" ... The Product Owner's intended perspective is "outward facing," while the team's own (the Scrum Master's ...) perspective is simultaneously "inward facing." Both of these parties need to simultaneously be looking at "the backlog." Which, in some ways, is "a to-do list." Yet, of ...


1

Product Backlog Refinement is essentially owned by the Product Owner but can involve the Developers for insights and their theoretical approach to implementation. Note that you don't simulate a small sprint planning here. The Whole Team includes the Scrum Master which ensures that the process takes place and the end goal is met as expected. The idea of this ...


1

It sounds to me like your very-small team also consists of, shall we say, "subject-matter specialists." And this might in the short run simply "be the hand that you've been dealt." But I think that you want to take every opportunity to emphasize that "we are all one team," and so, to the greatest extent possible, "we all ...


1

A really fun way is doing a Design Sprint. Followed by some Impact mapping and User story mapping. Depending on your product get out of the freaking building and let the developers talk to actual users. Maybe research the Shiftup program to help you facilitate continuous innovation. Bring the team together with the users and key-stakeholders, get and keep ...


1

As mentioned in other answers, you can go for story mapping exercise but first you may consider aligning all stakeholders to a prioritisation framework and high level objectives/ themes/ Epics (for the product you are building). The main problem with the bottom-up approach is the divergence of ideas from different individuals which may or may not be aligned ...


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