Tag Info

It depends vastly on several different factors, perhaps most importantly on which stage the Team is in in the 'Forming, Storming, Norming, Performing' process. If the Team is in the Performing stage (...

Call me a purist but I would say neither. There should be no accumulated technical debt if you are doing Scrum right. Remember: Individuals and interactions over processes and tools. Regardless of ...

What you've created is technical debt, and it needs to be refactored. Do not create duplicate stories, and try not to duplicate code as you just end up paying for things multiple times. A user ...

I'll share some potential downsides, but I'd be hard-pressed to say this approach is wrong if it's working for you. There are some reasons that I wouldn't do it, but that's different than wrong. So ...

In reality most teams go slower over time. This because the bigger the product becomes the higher the complexity becomes. This as more and more parts are depended on each other. To keep a high ...

If you have to do it in 2 places, I see 2 tasks. Remember that what you estimate and track is the time a task takes, not how much value is got by the client. And... yes, that duplicity is a problem ...

It can be used to identify long feedback cycles to shorten, impediments to be addressed, need for more shared understanding of items, large scope items that could be sliced more thinly, etc. Cycle ...

There's a school of thought that says: Don't estimate bug fixes, chores and spikes. This is because points should only be awarded to work that adds value to the business. Developers should be ...

The simple answer would be if the team is working on an item then it should be estimated. As an example if the PO decided to run a technical debt sprint, addressing no new features, at the end of the ...