User Stories કેવી રીતે લખવી (ઉદાહરણો અને Acceptance Criteria સાથે)
User story એ user ના દૃષ્ટિકોણથી feature નું ટૂંકું વર્ણન છે: "As a [user નો પ્રકાર], I want [goal] so that [કારણ]." તેની નીચે acceptance criteria લખો, કેટલીક ચોક્કસ શરતો જે story પૂર્ણ ગણાવા માટે સાચી હોવી જોઈએ. દરેક story એટલી નાની રાખો કે એક પાસમાં બનાવી અને ટેસ્ટ કરી શકાય, અને criteria એવા લખો કે કોઈ પણ તેને ચકાસી શકે.
User stories agile software teams દ્વારા લોકપ્રિય થઈ, પરંતુ જ્યારે તમે AI app builder વડે એકલા બનાવી રહ્યા હો ત્યારે પણ તે એટલી જ ઉપયોગી છે. સારી story એ સારો prompt છે.
ફોર્મેટ
User story ના ત્રણ ભાગ છે:
As a [કોણ], I want [શું] so that [શા માટે].
- કોણ એ ચોક્કસ પ્રકારનો user છે: પહેલી વાર આવનાર visitor, પૈસા ચૂકવતો member, clinic નો receptionist, admin. "user" નહીં.
- શું એ છે જે તેઓ કરવા માંગે છે, તેમના પોતાના શબ્દોમાં. Screen કેવી રીતે કામ કરે તે નહીં.
- શા માટે એ પરિણામ છે જેની તેઓ કાળજી રાખે છે. આ ભાગ લોકો છોડી દે છે, અને તે જ તમને ખોટું બનાવતા રોકે છે.
ઉદાહરણ:
As a gym member, I want to cancel a class booking from my phone so that someone on the waitlist can take my spot and I'm not charged a no-show fee.
"શા માટે" તમને બે બાબતો કહે છે જે "શું" એ કહી નહોતી: તે phone પર કામ કરવું જોઈએ, અને waitlist તથા fee ના નિયમો સામેલ છે.
Acceptance criteria
Story કહે છે કે શું જોઈએ છે. Acceptance criteria કહે છે કે તે ક્યારે પૂર્ણ છે. તે એટલા ચોક્કસ હોવા જોઈએ કે બે લોકો સંમત થઈ શકે કે દરેક પાસ થાય છે કે નહીં.
તેમને લખવાની સામાન્ય રીત Given / When / Then છે:
- Given એક શરૂઆતની સ્થિતિ
- When user કંઈક કરે
- Then આ પરિણામ છે
gym booking story માટે:
- Given મારી પાસે 12 કલાકથી વધુ દૂરની booking છે, when હું Cancel ટેપ કરું અને પુષ્ટિ કરું, then booking દૂર થાય અને મને "Booking cancelled" દેખાય.
- Given હું booking cancel કરું અને class માં waitlist છે, when cancellation સાચવાય, then waitlist પરની પહેલી વ્યક્તિને જગ્યા અને email મળે.
- Given 12 કલાકથી ઓછા સમયમાં booking છે, when હું Cancel ટેપ કરું, then પુષ્ટિ કરતા પહેલાં મને દેખાય કે late-cancellation fee લાગુ પડે છે.
- Given હું phone-પહોળાઈની screen પર છું, then Cancel બટન બાજુ સ્ક્રોલ કર્યા વિના દેખાય.
સાદી ચેકલિસ્ટ પણ ચાલે, જ્યાં સુધી દરેક વસ્તુ ચકાસી શકાય. "Cancelling સરળ છે" ચકાસી શકાય તેવું નથી. "Booking list માંથી cancel માટે વધુમાં વધુ બે ટેપ" ચકાસી શકાય તેવું છે.
પગલાવાર: સારી story કેવી રીતે લખવી
પગલું 1: વાસ્તવિક user અને વાસ્તવિક સમસ્યાથી શરૂ કરો
એક પ્રકારનો user અને તેમને આજે જે મુશ્કેલી પડે છે તે પસંદ કરો. જો તમે customer interviews કર્યા હોય, તો તેમના શબ્દો વાપરો. "હું હંમેશા cancel કરવાનું ભૂલી જાઉં છું અને ચાર્જ લાગે છે" એ "cancellation feature ઉમેરો" કરતાં વધુ સારી શરૂઆત છે.
પગલું 2: એક-લાઇનની story લખો
ટેમ્પલેટ ભરો. જો તમે વિશ્વાસપૂર્વક "so that" ન લખી શકો, તો પૂછો કે શું feature ની ખરેખર જરૂર છે.
પગલું 3: ત્રણ થી છ acceptance criteria ઉમેરો
પહેલા મુખ્ય સફળતાનો કેસ આવરી લો, પછી મહત્વની ભિન્નતાઓ: અલગ ભૂમિકા, ખાલી state, મર્યાદા, ભૂલ. જો તમે છથી વધુ લખી રહ્યા હો, તો story કદાચ ઘણી મોટી છે.
પગલું 4: શું બહાર છે તે નોંધો
એક લીટી ઘણી આપ-લે બચાવે છે: "Out of scope: paid classes માટે refunds; admins members વતી cancel કરે." તે બનાવતી વખતે story વધતી અટકાવે છે.
પગલું 5: INVEST સામે તપાસો
INVEST સારી stories માટેની સામાન્ય ચેકલિસ્ટ છે. Story આ હોવી જોઈએ:
| અક્ષર | અર્થ | ઝડપી ટેસ્ટ |
|---|---|---|
| I | Independent (સ્વતંત્ર) | બીજી story ની રાહ જોયા વિના બનાવી શકાય |
| N | Negotiable (વાટાઘાટ યોગ્ય) | જરૂરિયાત વર્ણવે, નિશ્ચિત design નહીં |
| V | Valuable (મૂલ્યવાન) | શિપ થાય તો user નોંધે |
| E | Estimable (અંદાજી શકાય) | તેનું કદ લગભગ અંદાજી શકાય |
| S | Small (નાની) | એક બેઠકમાં બનાવી અને ટેસ્ટ થાય |
| T | Testable (ટેસ્ટ યોગ્ય) | દરેક acceptance criterion ચકાસી શકાય |
દરેક story ને માર્ક કરવી જરૂરી નથી. જ્યારે story ખોટી લાગે અને તમારે કારણ જાણવું હોય ત્યારે તે સૌથી ઉપયોગી છે.
સારા અને નબળા ઉદાહરણો
| નબળી story | સમસ્યા | સારી story |
|---|---|---|
| As a user, I want a dashboard. | ચોક્કસ user નથી, કારણ નથી, ચકાસી ન શકાય | As a shop owner, I want to see today's orders and revenue on one screen so that I know at a glance if the day is going well. |
| As an admin, I want the database to have a status column. | અમલીકરણ વર્ણવે, જરૂરિયાત નહીં | As an admin, I want to mark orders as shipped so that customers stop emailing to ask where they are. |
| As a customer, I want to manage my account. | ખૂબ મોટી: ઘણી features આવરી લે | As a customer, I want to change my email address so that receipts go to my new inbox. |
| As a visitor, I want the site to be fast. | Story નથી; દરેકને જોઈતી ગુણવત્તા | તેને દરેક story પર criterion તરીકે લખો, અથવા અલગ performance લક્ષ્ય તરીકે. |
મોટી story કેવી રીતે વિભાજિત કરવી
મોટી stories એ છે જ્યાં પ્રોજેક્ટ અટકે છે. વિભાજનની સામાન્ય રીતો:
- user ભૂમિકા પ્રમાણે. Members પોતાની bookings cancel કરે; staff કોઈપણની cancel કરે.
- flow ના પગલા પ્રમાણે. Classes બ્રાઉઝ કરો; class book કરો; reminder મેળવો.
- સરળ કેસ પહેલા. મફત class હમણાં cancel કરો; fees અને refunds પછીની story માં.
- data ની ભિન્નતા પ્રમાણે. પહેલા એક location, પછી ઘણા.
- Happy path, પછી ભૂલો. પહેલા તે કામ કરતું બનાવો, પછી ભરેલા classes, સમાપ્ત થયેલા passes વગેરે માટે હેન્ડલિંગ ઉમેરો.
દરેક ટુકડો હજુ પણ એવું કંઈક હોવું જોઈએ કે user તેનો ઉપયોગ કરી શકે અને નોંધે.
User stories ને prompts તરીકે વાપરવી
Acceptance criteria સાથેની user story AI app builder માટેના સારા prompt ની ખૂબ નજીક છે. તે AI ને કોણ, શું, શા માટે અને "પૂર્ણ" ની વ્યાખ્યા આપે છે. દરેક message માં એક story મોકલો:
As a gym member, I want to cancel a class booking from my phone so that someone on the waitlist can take my spot. Acceptance criteria:
- Cancel દરેક booking પર My Bookings માં છે, પુષ્ટિ પગલા સાથે.
- 12 કલાકથી વધુ પહેલાં cancel કરવાથી booking ફક્ત દૂર થાય.
- 12 કલાકથી ઓછા સમયમાં, પુષ્ટિ પહેલાં "A late-cancellation fee of $5 applies" બતાવો, અને booking પર fee નોંધો.
- જો class માં waitlist હોય, તો પહેલી વ્યક્તિને જગ્યા અને email મળે.
- ફોન-પહોળાઈની screen પર કામ કરે. Out of scope: refunds, staff members વતી cancel કરે. આ બનાવો, પછી preview માં દરેક criterion તપાસો અને કયા પાસ થાય છે તે મને કહો.
તમે AI ને અસ્પષ્ટ વિચારમાંથી stories ડ્રાફ્ટ કરવા પણ કહી શકો, પછી તમે જાતે સંપાદિત કરો:
અહીં મારો એપ વિચાર છે: [બે કે ત્રણ વાક્યો]. પહેલા version માટે user stories લખો, user પ્રકાર પ્રમાણે જૂથબદ્ધ, દરેકમાં 3 થી 5 Given/When/Then acceptance criteria. ચિહ્નિત કરો કે કઈ launch માટે અનિવાર્ય છે અને કઈ રાહ જોઈ શકે.
હંમેશા પરિણામ વાંચો અને સંપાદિત કરો. AI તમારા users જાણતું નથી; તમે જાણો છો.
Acceptance criteria તમારી ટેસ્ટ યોજના તરીકે પણ કામ કરે છે. જ્યારે story બની જાય, ત્યારે દરેક criterion જાતે ચકાસો. અમારી લોન્ચ પહેલાં તમારી એપ ટેસ્ટ કરવી guide આના પર બાંધે છે.
User stories અન્ય દસ્તાવેજો સાથે ક્યાં બેસે છે
- Product requirements document આખા product નું વર્ણન કરે છે: સમસ્યા, users, scope. User stories તેની અંદરના વિગતવાર ટુકડા છે. જુઓ AI વડે PRD કેવી રીતે લખવો.
- Bug report એવી વસ્તુનું વર્ણન કરે છે જે પહેલેથી બનેલી story સામે તૂટેલી છે. જુઓ સારો bug report કેવી રીતે લખવો.
- MVP એ stories નો સૌથી નાનો સમૂહ છે જે મુખ્ય મૂલ્ય આપે છે. જુઓ MVP શું છે.
સામાન્ય ભૂલો
- "As a user…" ખૂબ અસ્પષ્ટ. user નો ચોક્કસ પ્રકાર નામ આપો.
- "so that" છોડી દેવું. કારણ વિના, તમે સમજદાર trade-offs કરી શકતા નથી.
- Need ને બદલે solution લખવું. "મને dropdown જોઈએ" કોઈએ વિચાર્યું તે પહેલાં design લોક કરી દે છે.
- ચકાસી ન શકાય તેવા criteria. "સરળ", "ઝડપી" અને "સહજ" ઇચ્છાઓ છે, criteria નહીં.
- જે ખરેખર epics છે તેવી stories. "મારો account સંચાલિત કરો" એ દસ stories છે.
- બધી stories પહેલેથી લખી નાખવી. આગામી થોડી વિગતે લખો; બાકીની એક-લાઇનની રાખો જ્યાં સુધી તમે ત્યાં ન પહોંચો.
Mythex માં stories
Mythex માં, Plan mode વિચારને stories માં ફેરવવા માટેની સારી જગ્યા છે: agent કંઈ સંપાદિત કરતા પહેલાં approach વિશે ચર્ચા કરે છે. જ્યારે story તૈયાર હોય, ત્યારે Build પર સ્વિચ કરો અને તેને પેસ્ટ કરો, એક message માં એક story. દરેક પછી, /test preview માં ક્લિક કરીને flow ચકાસી શકે છે, અને જો કંઈ ખોટું થાય તો કોઈપણ reply ને Revert to this point વડે પાછો વાળી શકો છો. Docs માં અસરકારક prompts જુઓ, અને AI app builders માટે prompts કેવી રીતે લખવા વિશેની અમારી guide.
User story ચેકલિસ્ટ
- એક ચોક્કસ પ્રકારના user નું નામ આપે છે
- જરૂરિયાત વર્ણવે છે, design નહીં
- વાસ્તવિક "so that" કારણ શામેલ છે
- ત્રણ થી છ ચકાસી શકાય તેવા acceptance criteria છે
- ઓછામાં ઓછો એક edge case અથવા ભૂલ આવરી લે છે
- શું બહાર છે તે જણાવે છે
- એક વારમાં બનાવી અને ટેસ્ટ કરી શકાય એટલી નાની
- બનાવ્યા પછી criteria એક પછી એક તપાસેલા
પ્રશ્નો
User story નું ફોર્મેટ શું છે?
સામાન્ય ટેમ્પલેટ છે: As a [user નો પ્રકાર], I want [કોઈ goal] so that [કોઈ કારણ]. તેના પછી acceptance criteria આવે છે, એવી ટૂંકી શરતો જે story પૂર્ણ ગણાવા માટે સાચી હોવી જોઈએ.
Acceptance criteria એટલે શું?
Acceptance criteria એવી ચોક્કસ, ચકાસી શકાય તેવી શરતો છે જે વ્યાખ્યાયિત કરે છે કે user story ક્યારે પૂર્ણ છે. તે ઘણીવાર Given / When / Then તરીકે લખાય છે: આપેલી શરૂઆતની સ્થિતિ, જ્યારે user કંઈક કરે, ત્યારે ચોક્કસ પરિણામ આવે.
User story કેટલી મોટી હોવી જોઈએ?
એટલી નાની કે એક બેઠકમાં બનાવી અને ટેસ્ટ કરી શકાય, અને છતાં પોતાની રીતે મૂલ્યવાન. જો story માં પાંચ કે છ કરતાં વધુ acceptance criteria હોય અથવા ઘણી screens આવરી લે, તો તેને user ભૂમિકા, flow ના પગલા, અથવા પહેલા સરળ કેસ અને પછી edge cases પ્રમાણે વિભાજિત કરો.
શું AI વડે બનાવતી વખતે user stories ઉપયોગી છે?
હા. Acceptance criteria સાથેની user story આદર્શ prompt ની નજીક છે: તે કહે છે કે feature કોના માટે છે, તેમને શું જોઈએ છે, અને તે કામ કરે છે એ કેવી રીતે ચકાસવું. દરેક message માં એક story મોકલવાથી AI ના ફેરફારો પણ નાના અને ટેસ્ટ કરવામાં સરળ રહે છે.