New answers tagged

0

These are pretty good answers, but I would suggest that there is pair programming (2 people) and there is mob programming (whole teams) and there is swarming (some group of people on each of several tasks). I've seen "teams" which were basically talent pools using this multi-mob kind of swarming to complete tasks. The team member all worked with ...


0

One thing I would consider is the size of your stories. Can you break them down into smaller chunks, so that it is easier for new pair combinations to pick up? Are you frequently running into a single story taking a sprint or more worth of work? Can you scope a story down to one to two days, making larger more complex features into smaller vertical slices of ...


3

Your approach for processing support requests seems to be very structured (some would say rigid). It could be a good guidance, or at least a checklist for making sure that nothing was forgotten. But where do the hypothetic timing come from? Is this just a gut feeling? Did you just try your approach on some simple issues? So before setting any timing ...


4

Creating a standard timeframe for resolving issues seems like a good idea, until an issue doesn't fit well into the timeframe. It's been my experience that you cannot predict these sort of things. The only thing in your proposed workflow that seems risky is the amount of time you expect to spend. Each work request, be it an enhancement or defect, will go ...


Top 50 recent answers are included