Изяснени Story Points и относителна оценка
Разберете story points и относителната оценка в Scrum. Научете защо екипите ги използват, как работят и техните ползи за планиране и прогнозиране, обяснени ясно.
Много Scrum екипи използват story points за оценка на усилието, необходимо за завършване на елементи от Product Backlog. Тази практика, наречена относителна оценка, помага на екипите да планират работата си, без да се затъват в прецизни времеви ангажименти. Тя не е изискване на Scrum Guide, но е широко възприета техника, която подкрепя емпиризма и самоуправляващите се екипи. Целта е да се разбере размерът на работата спрямо друга работа, а не да се прогнозират точни часове или дни.
Какво е относителна оценка?
Относителната оценка означава сравняване на един работен елемент с друг. Вместо да каже 'това ще отнеме 8 часа', екипът може да каже 'това е два пъти по-голямо от онова друго нещо, което направихме'. Този подход признава, че прогнозирането на точно време за сложна, нова работа е трудно и често неточно. Като се фокусират върху относителния размер, екипите могат да правят по-последователни преценки. Той измества фокуса от продължителността към възприеманото усилие, сложност и риск.
Защо Story Points?
Story points са абстрактни единици. Те не са обвързани с часове или дни. Тази абстракция помага да се избегне често срещаният капан за преобразуване на оценки в фиксирани крайни срокове, което често води до натиск и неточни прогнози. Story points насърчават дискусия между Developers относно включената работа, което води до споделено разбиране. Когато екипът присвоява story points, той взема предвид фактори като:
- Необходимо усилие за завършване на елемента.
- Сложност на елемента.
- Несигурност или риск.
- Зависимости от други системи или екипи.
Scrum Guide посочва, че Developers са отговорни за създаването на план за Sprint, който включва избор и оценка на елементи от Product Backlog. Story points подкрепят това, без да изискват от Product Owner да диктува как трябва да се извърши работата. Developers са тези, които са най-добре позиционирани да оценят работата.
Как екипите използват Story Points
Обикновено екипът установява базова линия. Те избират малък, добре разбран елемент от Product Backlog и му присвояват ниска точкова стойност, да речем 1 или 2. След това всички останали елементи се оценяват спрямо тази базова линия. Често срещани поредици за точкови стойности включват поредицата на Фибоначи (1, 2, 3, 5, 8, 13, 21...) или опростена версия. Тази нелинейна скала отразява нарастващата несигурност, която идва с по-големите елементи. 13 не е просто три пъти по 5, а предполага по-големи неизвестни.
По време на Product Backlog Refinement, Developers обсъждат елементи и присвояват точки. Ако има голямо несъгласие, това сигнализира за различни разбирания на работата, което подтиква към по-нататъшна дискусия. Този процес изгражда споделено знание и обща дефиниция за 'done' за елемента. Product Owner гарантира, че Product Backlog е прозрачен, разбран и прецизиран, но оценката на усилието е отговорност на Developers.
Скорост (Velocity) и прогнозиране
След няколко Sprints се появява 'скоростта' (velocity) на екипа. Скоростта е сумата от story points за всички елементи от Product Backlog, успешно завършени в даден Sprint. Това е емпирична мярка. Тя е историческа средна стойност, която помага на екипа да прогнозира колко работа може реалистично да поеме в бъдещи Sprints. Това е инструмент за Developers да управляват собствения си капацитет и за Product Owner да взема информирани решения относно бъдещото развитие на продукта. Скоростта е екипна мярка, а не индивидуална, и не трябва да се използва за сравняване на екипи или индивиди.
Product Owner може да използва скоростта, за да прогнозира кога може да бъде завършена по-голяма част от работата, въз основа на общия брой точки, оставащи в Product Backlog. Това е прогноза, а не гаранция. Scrum Team непрекъснато инспектира и адаптира тази прогноза, тъй като научава повече. Ключът е прозрачността и честата корекция.
Често срещани клопки, които трябва да се избягват
Не третирайте story points като мярка за продуктивност на индивиди. Това подкопава екипното сътрудничество и прозрачността. Не преобразувайте story points в часове. Това обезсмисля относителната оценка и въвежда отново проблемите на времево базираното оценяване. Story points са комуникационен инструмент за Developers, за да им помогнат да разбират и планират работата си, и за Product Owner да прогнозира. Те не са договор или показател за ефективност.