Para saan ba yung User Stories?
Team Weeknotes #1 (Tagalog)
*Read this post in English.
Hindi ko alam kung gaano karami sa digital product development field ang familiar sa User Stories sa ngayon.
May mga sumikat na na article na pinapa-tweak ‘yung “user stories” into “job stories”. So, pwede nating sabihin na either sumisikat siya lalo, o malapit na siyang malaos. Pero bago gumulo ang usapang user stories, gusto muna namin ikwento kung bakit may particular na benefits siya sa ‘min.
Itong linggo na ‘to, halos lahat ng project namin ay nagbago ng scope. At dahil dun, kaya namin naisip ikwento ang relevance ng User Stories.
Dahil sa panahong nagbabago ang project scope, na hindi natin (ever) maiiwasan, ramdam mo yung importance ng Project at Product Management.
Technically, ang User Stories ay Project Management tool.
Ginagamit sila ng Project Managers para:
1. Mag-track ng project scope.
2. Mag-set ng clear “success” or “accomplishment” metrics para sa bawat task.
Lalo na kapag ang ginagamit mo na methodology sa product development ay “Scrum”. (Isang tipo ng methodology under Agile — isang style ng project management that values “Ano lang muna yung pinaka-pinaka-kailangan ilaunch” — or Minimum Viable Product. Tapos “dagdagan na lang natin pagkatapos, kapag mas may data na tayo” —or Iterative.)
So ano’ng koneksiyon nito sa pabago-bago na scope?
- Kapag meron ka kasing set ng kumpletong user stories — pag nilista mo sila lahat — dapat para siyang encyclopedia o bible ng lahat ng nagagawa or pwedeng magawa ng product mo. Dahil dito, kaya useful din siya sa Product Management.
- Pwedeng mag-align yung team at ipako ng product manager at project manager na “Ito lang ang mga ide-develop” na tasks sa release na ‘to. Lahat ng ibang story, sa susunod pa na launch.
Warning: Mga doble yung tagal ng pagsulat at pag-align ng user stories kumpara sa inaakala mo sa simula.
Ano ba’ng special sa user stories?
Actually, wala.
Joke. Pero medyo seryoso. Walang magic sa “user stories”. Hindi porke’t nag-user stories ka, parang hiwaga na aayos yung project releases niyo.
Kailangan alam niyo sila isama at respetuhin, sa team ninyo. Para niyo siyang bagong team member.
Anyway, ang user story ay format ng kung paano isulat ang “user tasks” ng isang product.
Ano ang Kakaiba sa User Story
1. May tatlong required section ang user story: Actor, Action at “Achievement”.
Meaning:
- Ano’ng klaseng website/app user lang yung pwedeng gumawa nun?
- Ano’ng pwede niyang gawin?
- O tapos? Ano bang makukuha niya pag nagawa niyo yung action?
2. Sa classic na execution, ang User Story ay naka-card.
Bakit? Dahil ang ideal na paggamit ay sama-sama ‘yung team, tapos pag-uusapan ninyo yung user stories, lalagyan niyo ng number rating ng “Importance” at “Feasibility” or “Time that it will take to develop”, tapos ishu-shuffle o -cluster niyo depende sa gusto niyong isama sa unang release.
3. ‘Yun yung classic. Ito yung practical.
Sa tunay na buhay, t-in-ry na rin namin ‘yung cards.
Cute siya, at engaging. Nagfo-foster nga siya ng team discussion kasi pwede niyo lahat hawakan at basahin.
So okay siya. Kapag 12–20 lang yung actions ng product mo.
Kunwari: upload a text post, edit a text post, delete a text post, register, log-in, edit personal profile, delete a profile, follow a person, unfollow a person, post an image, delete an image, see posts from a user.
‘E mabibilang ko pa lang ata sa isang kamay kung ilan lang ang project na may 12–20 tasks.
Paano kapag 60+ yung tasks ng isang website? Paano kung gumagawa ka ng platform? Paano kung gumagawa ka ng game? Kung saan bawat motion, sa bawat stage or pag-react sa isang object ay task.
Pasok — Excel file.
So, dito mas nagiging relevant ang spreadsheet. Hindi siya kasing-cute ng cards. Pero mas madali mag-sort at list ng actions kapag ganito.
Bonus round: May isa pang benefit ang User Stories sa amin, kaya gusto namin siya ginagamit lalo na kapag unang nagw-wireframe.
Masaya siyang gamitin para sa design.
Tinuro ata ito ng isa sa mga nauna naming boss na developer. Kapag “features list” ang binigay mo sa isang designer (e.g. “Carousel” — Pasensiya na, 2011 nun. ‘Yun yung “hot new thing”. Nung 2012 naman, “Parallax”.), tinatali mo na siya sa pag-design ng iisang klase ng execution — “A ok, lagyan ng carousel yung home.”
Lumalaki yung tendency na magkakamukha yung mga website dahil inuutos mo na yung execution nung actions.
Pero paano kung ang user action mo lang naman ay gusto mong makapag-present ng multiple images to users on a homepage, while allowing them to focus on one image first, and minimizing space used? (Essentially, yun ang ginagawa ng “carousel” na design pattern).
‘Yun ang way to allow designers to think more flexibly.
To think of the “goal” and how to get there creatively, rather than follow an execution, and then look for creative ways to make that ornamental.
Case in point: ‘Nung usong-uso mag-redesign ng content website — puro carousel yung na-audit namin.
Until naglabas ang The Verge ng:
Same goal, different strategy.
Balik tayo sa last week. So bakit naalala namin ang kahalagahan ng user stories?
Kasi kapag nagbabago ang scope, sobrang nakakatulong na may nababalik-balikan ka na encyclopedia ng lahat ng dapat niyong dinedevelop — para balikan at i-refresh sa utak ng lahat na “Guys, ito yung roadmap natin”.
Kahit pa mahirap siyang i-update minsan.
Note: Tulad ng nabanggit kanina, hindi end-all, be-all ang user stories. Isa lang siya sa maraming paraan na mag-document ng features at tasks ng product. Kung may alam ka pang iba na nakakatulong sa inyo, we’d love to hear about them. Usap tayo minsan.
Extra reading: Kung natuwa kayo sa concept ng user stories, ito yung isang article na nag-lead sa pagsabi na kailangan gawing mas specific pa ang “user stories” (at gawing “job stories”), na sinulat ng @Intercom.io team.
Ang mga alam namin tungkol sa trabaho ay hindi lang nanggaling sa college degree, sa projects, boss at katrabaho — pero pati sa mga designer, developer, researcher, product manager at team na piniling i-bahagi at ipakita ang proseso at natutunan nila (ng libre) sa Youtube, blogs, websites, tutorials at MOOC (Massive Online Open Courses). Ito ang spirit ng “designing in the open”. Kung saan bukas na kinukwento ang mga proseso at output ng isang design team. Para lalong mapalago ang kaalaman ng buong industriya, pati na rin para makakuha ng feedback at dialogue tungkol sa trabaho.
(Para lalong maintindihan ang halaga at kagandahan ng open design, pwede niyong basahin ‘to.)
Dito sa weeknotes namin kinukwento ang mga nararanasan namin sa trabaho linggo-linggo. Bilang paggalang sa mga kliyente namin, hindi namin sila pinangangalanan o binabanggit. Lahat ng mga sinusulat namin dito ay isip at opinyon ng nagsulat.
Kung gusto niyo pa kaming samahan sa mga napapagdaanan namin linggo-linggo, sundan niyo kami dito sa Medium, Facebook o LinkedIn.Sali din kayo sa buwan-buwan namin na e-mail newsletter, para sa mga link at article na nakita naming useful sa trabaho at project.
