1. SP - это линейка для измерения сложности. Что-то совсем простое = 1, что-то сложное = 13. Это относительна шкала, поэтому у всех она своя. Оценки в SP эмпирические, то есть основанные на предыдущем опыте. Если что-то не понятно во сколько оценить, то нужно это разбить на кусочки и каждый оценить в отдельности.
2. У разработчиков есть такая же проблема, обсудите с ними. Она называется "технический долг". Каждое изменение в функциональности требует переписывания чего-то ранее написанного. Эта как-бы лишняя работа крадет время и снижает скорость команды. Очевидно, что с этим нужно бороться.
Я знаю два подхода, которые здесь можно применить:
а) Выстраивать инкрементальную разработку (это типа тщательнее подбирать истории для автоматизации, да), то есть глубже продумывать каждую историю и делать функциональность последовательно, чтобы следующие спринты сильно не ломали то, что было сделано на предыдущих. Это командная работа - всегда можно найти какой-то компромисс, главное, чтобы все понимали, что каждому решению есть цена.
б) Непрерывно улучшать дизайн (кода и тестов) с той целью, чтобы поддержка новых историй не требовала много времени. Это уже только в руках разработчика/тестировщика - делать гибкий дизайн. Банальный пример, в автоматических тестах привязываться не к названиям, и не расположению их внутри модели UI, а только к ИД элементам интерфейса.
Простой
