Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

New answers tagged

1

We allocate 10% as a buffer time to accommodate any urgent requests or change requests that come after the start of the sprint. Obviously it would mean re estimation and realignment of priorities. Anything more than 10% we move out other tasks with similar estimates. I know it defeats the purpose of having the sprint if you resuffle the tasks midway, but ...


0

In my experience it is best to keep the current sprint backlog relatively static, but if the new requirement cannot wait until the next sprint, I believe the only sensible way to deal with an additional requirement is to trade it with another similar sized requirement. If you allow things to be added you run the risk of the whole process of scrums and/or ...


3

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 ...


0

Although Agile is setup to expect and to handle change, there isn't a great deal of detail in Agile frameworks about how to handle contract changes. The assumption is that in an Agile delivery some mechanism will be put in place to deal with significant changes (i.e. change requests). For example, some organisations will work using 'time & materials' ...


2

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


Top 50 recent answers are included