ऐसी user story आप कैसे लिखते हैं जो इंजीनियरों को सचमुच काम की लगे?

काम की stories सिर्फ क्या नहीं, क्यों और सीमा भी ढोती हैं। यूजर और नतीजा वाक्य में रखिए, फिर अपनी ज्यादातर मेहनत उन acceptance criteria पर लगाइए जो edge cases का नाम लें: खाली state, permission नहीं है, offline, और नाकामी पर क्या होता है। इंजीनियरों को कविता नहीं चाहिए, उन्हें यह जानना है कि वे कब पूरा कर चुके और कौन से मामले वे बेखटके छोड़ सकते हैं।

जो हिस्सा इंजीनियर सचमुच इस्तेमाल करते हैं वह acceptance criteria है, इसलिए मैं अपना वक्त वहीं लगाता हूं। story वाला वाक्य एक लाइन में क्यों बता देता है, लेकिन फिर मैं मामले गिनाता हूं: खाली state पर क्या होता है, बिना permission वाले यूजर को क्या दिखता है, अगर request बीच में फेल हो जाए तो क्या होता है, धीमे connection पर हम क्या करते हैं। ये वही सवाल हैं जिनके लिए वरना तीन दिन बाद मुझे Slack पर टोका जाता, और इनमें से हर एक ऐसा फैसला है जो मुझे करना चाहिए, न कि रात ग्यारह बजे कोई इंजीनियर अंदाजे से करे। मैं यह भी लिख देता हूं कि क्या साफ तौर पर बाहर है, क्योंकि इससे नेकनीयत सजावट रुक जाती है। और ticket का अनुमान लगने से पहले मैं criteria इंजीनियर को दिखा लेता हूं। इसमें दस मिनट लगते हैं और आम तौर पर कोई एक ऐसी जरूरत सामने आ जाती है जो तकनीकी तौर पर महंगी है और यूजर को उससे लगभग कुछ नहीं मिलता, जिसे मैं फिर हटा सकता हूं। जिस story का अनुमान उस बातचीत के बिना लग गया, वह असल में एक ख्वाहिश भर है।