สร้าง product backlog item หรือ user story...

USER STORYscenario based requirement

16 May 2014

As an operator, I want a verify identity screen

so that I can see customer details and verify his/her identity to process

her request

ในฐานะเจ้าหน้าที่ อิฉันอยากจะได้หน้า VERIFY เพื่อที่จะได้เห็นข้อมูลลูกค้า

และให้ลูกค้ายืนยันตัวตน ก่อนที่ทำสิ่งที่เค้า REQUEST เข้ามา

ในฐานะ OPERATOR( As an operator )

อิฉัน อยากจะได้ หน้าจอ VERIFYI want to have verify screen

เพื่อที่จะเอาไว้ใช้ ยืนยันตัวตนลูกค้าที่ติดต่อเข้ามาSo that I can verify customer identity

การเขียนเสป็คงานProduct Requirement

USER STORY

• เพราะเราสนใจ การใช้งานของ User เวลาเราทำเสป็คงาน จึงไปตั้งต้นที่ การใช้งานตามที่ user จะใช้

องค์ประกอบของ USER STORY

• As a ________

• I want _______

• So that_______

รายละเอียดแนบ USER STORY

• Requirement No: ( high level requirement number )

• Sub Requirement No: ( low level requirement number)

• Category: (if any)

• Scenario:

• Sub Scenario

รายละเอียดส่วนที่เป็น อุปกรณ์เป้าหมาย

• Target Device(s):

• Resolution:

• Device/ OS Remark:

STAKEHOLDER

• ตามที่ระบุไว้ใน “As a”

• หรือมีคำบรรยายเพิ่มเติม

IMPACT• [ ] กิจกรรมใหม่ New User Activity / Business Activity

• [ ] ทำให้ของเดิมเร็วขึ้น

• [ ] ทำไปแทนที่ของเดิมที่เราจะเลิกใช้

• [ ] ลดข้อผิดพลาด

• [ ] ผิดพลาดสำคัญ

• [ ] ผิดพลาด Minor และมี workaroundแก้ปัญหาเฉพาะหน้าชั่วคราวได้

• [ ] ลดค่าใช้จ่าย เช่นหลีกเลี่ยงค่า license ได้

• [ ] ตอบโจทย์ข้อบังคับทางกฎหมาย

• [ ] เพื่อเก็บข้อมูลไปวิเคราะห์ทางธุรกิจ หรือทำความเข้าใจ user

RISK

• ส่วนที่ยังไม่แน่ใจ

• เช่น อยากใช้การ ลากวาง แทน คลิกๆ หลายครั้ง

PREPARATION

• สิ่งที่เราต้องไปทำการบ้านเพิ่มเติม ก่อนเค้าจะเริ่มงานแล้วเอากลับมาใส่ข้อมูลเพิ่มเติม

BUSINESS VALUE

• ถ้าเรามีความชัดเจนว่า เกี่ยวกับ Business Value

• ขอใส่ข้อมูลลงไปด้วย

ส่วนเสริมเรื่องประสิทธิภาพ

• เช่น หน้านี้ไม่ควรใช้เวลาโหลดเกิน 10 วินาที

• หน้านี้ ต้องสะอาด ไม่ scroll เยอะ

• ไม่ควรต้องคลิกออกไปข้างนอกเยอะ

บันทึกสำหรับการตรวจงาน

• เวลาตรวจงาน อยากตรวจอะไรบ้าง

• ให้ออกแบบไว้ก่อน ไม่อย่างนั้นเดี๋ยวตอนตรวจจริงจะลืม

ตัวอย่างส่วนเสริมของ SPEC• ความเร็ว

• ช้าสักนิดก็ไม่เป็นไร ถ้าไม่เกิน 10 วินาที เพราะหน้านี้ไม่ได้เปิดตอนคุยกับลูกค้า เป็นต้น

• หน้าร้องเรียน หรือติชม ต้องทำงานเร็ว เพราะลูกค้ามักติดต่อมาด้วยอารมณ์ขุ่นเคือง ถ้าระบบทำงานช้าลูกค้าอารู้สึกไม่พึงพอใจมากขึ้นไปอีก

ตัวอย่างส่วนเสริมของ SPEC• ความสวยงาม

• ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา

• มีความสะอาดสะอาด ไม่ดูเลอะเทอะ

• สีสันสดใส ไม่น่าเบื่อ

• เว้นช่องว่างระหว่างบรรทัดเยอะๆ เพื่อจะได้ดูโปร่งตา

ตัวอย่างส่วนเสริมของ SPEC

• การใช้งานของ user

• ความสะดวก จำนวนคลิก น้อยที่สุด

• ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่อยมือจากเมาส์น้อยที่สุด

REAL LIFE DATANo Lorem Ipsum.. and any Bla Bla data

SPECIFICATION TABLE (SPECIFICATION BY EXAMPLE)

วาดรูปหน้าจอ ประกอบเสป็ค

• เพื่อระบุ โครงหน้าให้ชัดเจน อยากได้อะไรไว้ตรงไหน

ACCEPTANCE CRITERIA

REQUIREMENT STATUS• Collect details and define scope

• Create scenarios

• Split scenarios (ได้อีกกี่ level ก็ได้)

• Journey breakdown

• Define specs (Specification By Example, Paper Mockup, Acceptance criteria)

• Create User Story

• Rearrange backlog and User stories