Проблемы Scrum Burndown [закрыто]

Мы используем Scrum около 9 месяцев, и это в значительной степени успешно. Однако, наши таблицы выживания редко выглядят как «модельные», вместо этого они больше напоминают ужасающую поездку на американских горках с некоторыми подъемами и падениями, вызывающими рвоту.

Чтобы попытаться бороться с этим, мы тратим больше времени на создание прототипа и разработку спринта, но мы все еще, кажется, обнаруживаем гораздо больше работы во время спринта, чем первоначально предполагалось. Примечание. Под этим я подразумеваю, что работа, необходимая для устранения отставания, является более сложной, чем кажется на первый взгляд, а не мы определили новые элементы для отставания.

Это общая проблема со Scrum, и есть ли у кого-нибудь советы, которые помогут сгладить поездку?

Я должен отметить, что большинство наших разработок не основано на новых технологиях, поэтому мы поддерживаем функциональность в существующем крупном и сложном приложении. Является ли scrum менее подходящим для этого типа разработки просто потому, что вы не знаете, какие проблемы будет создавать существующий код?

Сколько времени мы должны потратить, прежде чем спринт начнет прорабатывать детали развития?

ОБНОВЛЕНИЕ: у нас больше успеха и плавности. Во многом это связано с тем, что при оценке мы приняли более пессимистический взгляд, который дает нам больше передышки для того, чтобы иметь дело с вещами, когда они не идут по плану. Вы могли бы сказать, что это позволяет нам быть более гибкими. Мы также пытаемся изменить представление о том, что график выгорания является своего рода расписанием, а не указанием объема ресурсов.

Ответы на вопрос(11)

Ваш ответ на вопрос