PBI a historia użytkownika

Ostatnio właściciel produktu dodał do Backlogu produktu pozycję, która mówi: „Kiedy przechodzę do strony logowania ze strony x, widzę błąd. Chcę usunąć ten błąd”.

Wydaje mi się, że nie jest to przypadek użycia i nie powinien być PBI (pozycja Backlogu Produktu). Jednak, gdy o tym mówiłem, Scrum Master powiedział mi, że historie użytkowników nie są PBI, a PBI może być raportem o błędzie, zadaniem, historią użytkownika, czymkolwiek i dosłownie jakimkolwiek przedmiotem, który powinien zostać rozwiązany w pierwszej kolejności.

Nie jestem pewien co do tego. Nie mogę też znaleźć dobrej definicji PBI w sieci . Moje pytanie brzmi: jakie rzeczy mogą dostać się do Backlogu Produktu jako przedmioty? Czy element zaległości produktu jest mapowany na historię użytkownika? Czy oni są tacy sami?

Czy element zaległości produktu jest mapowany na historię użytkownika? Czy oni są tacy sami?

Niekoniecznie, ale generalnie tak. Jak powiedział mistrz scrum, inne rzeczy mogą być również elementami zaległości produktowych. Jednak to zależy od tego, jak swoją SCRUM działa. Niektóre zespoły mają osobne zaległości w błędach, które są również uwzględniane w sprintach, podczas gdy inne utrzymują takie rzeczy w zaległościach produktu.

Dwa oddzielne dzienniki utrudniają właścicielowi produktu ustalenie priorytetów zadań, ponieważ teraz należy wziąć pod uwagę dwa dzienniki podczas następnego sprintu. Ale oferują lepszy nadzór i oba mogą być traktowane priorytetowo osobno.

Moje pytanie brzmi: jakie rzeczy mogą dostać się do Backlogu Produktu jako przedmioty?

Może to być wszystko, co jest częścią wizji produktu i drogi do produktu, który chcesz stworzyć. Zawiera głównie wymagania (historie użytkowników), ale może także zawierać działania lub rzeczy techniczne, które nie należą bezpośrednio do produktu (np. „Kup nowy serwer dla zespołu programistów”, „Utwórz reklamę produktu”). Zaległości powinny unikać niepotrzebnych szczegółów i nie powinny próbować mikromanalizować rzeczy technicznych. Backlog produktu może zawierać wszystko, co zapewnia wartość produktu.

Nie ma jednego prawdziwego Scruma. Czasami oddzielne zaległości są lepszym sposobem zarządzania produktem, a czasem przeszkadzają. Dowiedz się, co działa najlepiej dla Ciebie.

Podczas pracy nad błędami dodajemy je do zaległości i nazywamy je historiami błędów . Dodając poprawki błędów do zaległości w ten sposób, jasne jest, że to nie tylko naprawa błędów. Możemy dodać inne zadania, aby upewnić się, że testy automatyczne są napisane i że weryfikacja jest przeprowadzona. Usprawnia także, że należy postępować zgodnie z DoD.

Nigdy nie używaliśmy terminu PBI (chociaż nasze narzędzie do obsługi zaległości tak je nazywa), zawsze są to historie użytkowników, historie błędów lub po prostu historie .

Jest to głównie wybór terminologii twojego zespołu i tak długo, jak wszyscy jasno rozumiesz, co nie ma znaczenia.

Wszystkie powyższe odpowiedzi nie odwołują się do wiarygodnego dokumentu źródłowego dla frameworka Scrum: Przewodnik Scrum .

Rejestr produktu

Istnieje sekcja opisująca Backlog Produktu i zawarte w nim elementy, często nazywane PBI.

Rejestr produktu zawiera wszystkie funkcje, funkcje, wymagania, udoskonalenia i poprawki, które stanowią zmiany, które należy wprowadzić w produkcie w przyszłych wydaniach.

Ale nie jest ustalony jak plan projektu.

Backlog produktu ewoluuje wraz z rozwojem produktu i środowiska, w którym będzie używany. Backlog produktu jest dynamiczny; ciągle się zmienia, aby określić, co produkt musi być odpowiedni, konkurencyjny i użyteczny.

Historia użytkownika

Termin historia użytkownika nigdy nie pojawia się w Poradniku Scrumowym, ponieważ

jest to struktura, w której możesz zastosować różne procesy i techniki.

Korzystanie z historii użytkownika jest tylko jedną z możliwych technik rejestrowania PBI.

DODATKOWO: Mimo że często widzi się format „Jako taki, chcę, więc taki”, może on być sprzeczny z jego pierwotną intencją . Ten kłopotliwy format został również rozwiązany na Agile 2017 .

@ Falcon dobrze to wyjaśnił. Jedna strona, która ma formalną definicję to: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog To, co opisałeś, nie powinno być umieszczane w rejestrze produktów przynajmniej zgodnie z tym opisem.

Istnieje powszechne nieporozumienie, że w historii produktu dozwolone są tylko historie użytkowników. Natomiast Scrum jest neutralny w stosunku do technik wymagań. Jak stwierdza Scrum Primer ,

Elementy Backlogu Produktu są wyrażane w dowolny sposób, który jest jasny i trwały. W przeciwieństwie do powszechnego nieporozumienia, Backlog Produktu nie zawiera „historii użytkowników”; po prostu zawiera przedmioty. Elementy te można wyrazić jako historie użytkowników, przypadki użycia lub inne podejście, które grupa uzna za przydatne. Ale niezależnie od podejścia, większość produktów powinna skupiać się na dostarczaniu wartości klientom. *

• Odrębne specyfikacje zmian i dodatków do produktu nazywane są elementami Backlogu Produktu (PBI), które razem tworzą Backlog Produktu.
• Każdy PBI opisuje coś, co programiści mogą opracować i dostarczyć, aby wnieść wartość dodaną dla odpowiednich interesariuszy po zakończeniu (patrz Definicja ukończenia).
• Najczęstszym interesariuszem jest rynek lub jego przedstawiciel - Właściciel produktu.
• Jednak PBI może opisywać pracę, która zmniejsza koszty dla przedsiębiorstwa lub zmniejsza wysiłek zespołu programistów, lub narzędzie, które pomaga zespołowi właściciela produktu lepiej wykonywać swoją pracę.
• PBI może opisać wszystko, co ma potencjalną wartość dla interesariusza.

Historia (użytkownika) jest pomocnym standardowym formatem elementów zaległości. Uzasadnieniem tego jest „jeśli nikogo to nie obchodzi, nie marnuj na to czasu”. Pozwala także PO ocenić pilność przedmiotu, ponieważ określa, dla kogo będziesz go robić i jak źle jest.

W twoim przypadku błąd można łatwo sformatować jako historię.

• Jako użytkownik
• Chcę móc zalogować się na stronie X (i zamiast tego nie wyświetlać błędu)
• więc nie będę tracić czasu, denerwować się i tracić wiary w produkt

To brzmi jak warte wysiłku.