466 9754 [email protected] Definition of “Done”: What is “done” to you? • When you say your software is “done”, what do you mean? • To respond: • Write a short list of what “done” means for you. (solo, 2 minutes) • Share your thoughts one of these ways: • Unmute your mic (and, optionally, enable your camera) and share a few items verbally. • Type your responses into the chat window Image: http://www.chicagonow.com/cubicle-dad/2011/09/letting-toxic-people-and-negative-thinking-affect-me-it-stops-now-its-done/
466 9754 [email protected] Definition of “Done”: What is “done” to you? • When you say your software is “done”, what do you mean? • Responses • PS (Nallasamy Ponnusamy): Done: Developed, tested and ready for production roll out • Kamran Zameer: Done means product owner accept the work that development is claiming that it is completed. • Greg Gerrein: Done: Product owner acceptance • Yetish Narayana: Done : Code developed, Unit tested and QA tested • Tomasz Skiba: - Working code - Unit and acceptance testing done- Approval for release • PS (Nallasamy Ponnusamy): • Justin Sanford: Done to me requires that all P1 goals are functioning as designed, all tests pass for the functionality covered by those goals, and no P1 bugs open • Jeffry Pincus: Done: required functionality and no known bugs. • Cornell Wright: Code is tested and ready for the user • Antonio Recalde: Done:- Done enough for deployment. If it is an incremental type of project, it is never really done as there can always be improvements, or new features.If it is a one time thing.. e.g... install software, it is done when the requirements are met. • Cyril (Tony) Allen: Done means the code is written, tested, and ready for commit/deployment. • Matt Kubej: Meets acceptance criteria, QA tested, Unit tested, No known defects • Frederick 2: Done: Developed, unit tested, qa tested, documented, accepted by stakeholders, published • Philip: The software has met the owner’s requirement per the RFP or agreement.
466 9754 [email protected] Definition of “Done” • Everyone must understand and agree on what “Done” means • Unique to each Scrum Team • If the org has “done” conventions/ standards/guidelines, the org’s Def of Done is the Scrum Team’s minimum Def of Done • Used to assess when work is complete on the product increment • More stringent as Scrum Team matures Source: The Scrum Guide 2013 Image source: http://www.signingtime.com/whats-the-sign-for-all-done/
466 9754 [email protected] Definition of “Done”: concrete practice • Define “done” for your HW2-3 mob • Try: Start with the sentence, “We’ll agree we’re done when:” and create a checklist of done-ness criteria • Try: Start with the “done” ideas that you already wrote down • Try: Use Decider Protocol to quickly agree on each proposed item • 5-10 minutes, then share with whole group
466 9754 [email protected] Definition of “Done”: concrete practice • Share your Definition of “Done” • At least one mob, what did you agree to as your Def of Done?
466 9754 [email protected] Definition of “Done”: conclusion • Clearly defined agreement amongst team members • Clearly defined for stakeholders • Guides estimating and Sprint Planning • Helps us deliver working—the primary measure of progress— software every sprint Image: http://blogs.edgehill.ac.uk/learningedge/author/wilcockm/
466 9754 [email protected] Definition of Ready: What do you think? • What would you like to know about a new software requirement before you start working on it? • To respond: • Write a short list of what “ready” means for you. (solo, 2 minutes) • Share your thoughts one of these ways: • Unmute your mic (and, optionally, enable your camera) and share a few items verbally. • Type your responses into the chat window Image: http://www.soarselling.com/blog/thoughts/are-you-ready-for-a-coach/
466 9754 [email protected] Definition of Ready: What do you think? • To be ready to implement a new software requirement, what do you want to know? • Responses • Kamran Zameer: requirements clearly defined and discussed • Justin Sanford: Functional use case defined and understood • Yetish Narayana: Requirements analysed and documented • alpana: requirements clearly communicated • Greg Gerrein: clear requirements and unblocked technically • Phillip Heller 2: Broad understanding and acceptance of requirements, agreement on tech stack and rough architecture • Philip: Requirement clearly understood • Qanit Al-Syed: - Requirements have an acceptance criteria - Requirements are understood by everyone - Everyone agrees on the effort/story points for each story. • Linghong Chen: requirement is well defined • Justin Sanford: Dependent work items complete, or on track for completion • Lori Higham: Ready is when we have defined the required criteria, including the definition of “done,” and have organized the steps one small block at a time in an outline. • Cornell Wright: Well understood & documented understanding of the software requirment • Usha: functional requirements and may need to understand the design from the architecture prespective • Frederick 2: Definition of ready: knowing requirements and intended outcome • Jeffry Pincus: Requirements understood, development environment configured. • Tomasz Skiba: - Scope of the features- Skills that are needed for development- Functional requirements- Non functional requirements
466 9754 [email protected] Definition of Ready • Like airline pilots’ preflight safety check • Helps you go faster: fewer impediments to getting Done • Ensures each PBI has value: if PO can’t articulate value, it’s not Ready Image source: https://www.mansfieldins.com/2014/07/22/im-ready-im-ready-im-ready-practice-makes-perfect-preparing-storm/
466 9754 [email protected] Definition of Ready: example • An actual team’s Def of Ready • Short name • User story • Use cases • Current product behavior • Future product behavior and consequences • Acceptance criteria • Test outline • Demo script • Data storage concerns • Code flows and sequence, data flows • Proof of concept / prototype • Review by other architect and team • Security review • UX spec • Complexity/size estimate Source: http://kasperowski.com/2011/10/get-ready-to-get- done-definition-of.html
466 9754 [email protected] Definition of Ready: concrete practice • Define Ready for your HW2-3 mob • Try: Start with the sentence, “We’ll be ready to work on this backlog item when:” and create a checklist of done-ness criteria • Try: Start with the “ready” ideas that you already wrote down • Try: Use Decider Protocol to quickly agree on each proposed item • 5-10 minutes, then share with whole group
466 9754 [email protected] Definition of Ready: concrete practice • Share your Definition of Ready • At least one mob, what did you agree to as your Def of Ready?
466 9754 [email protected] Definition of Ready: conclusion • Clearly defined agreement amongst team members • Clearly defined for stakeholders • Helps you go faster: fewer impediments to getting Done • Guides Product Owner, collaborating teams, and stakeholders • Helps us deliver working software— the primary measure of progress— software every sprint Image: http://mykidentity.com/?p=541
466 9754 [email protected] Sprint Retrospective: connection • Look back at the week you spent with your mob. • What went well that you would continue or amplify? • What would you change? Exactly how would you change it? • Is there someone you want to thank? Write a sentence like, Thank you, _____________ (person name), for ________ (thing you did). • To respond: • Write your list. (solo, 2 minutes) • Share your thoughts one of these ways: • Unmute your mic (and, optionally, enable your camera) and share a few items verbally. • Type your responses into the chat window Image: http://cmforagile.blogspot.com/2013/07/what-happens-in-retrospective-stays-in.html
466 9754 [email protected] Sprint Retrospective • Purpose: Optimize the Scrum Team • Diverge: collect wide range of ideas • Converge: bring the ideas together (affinity grouping, etc.) • Order: prioritize change items • Action plan: 1-3 improvements that you will make during the next sprint Image source: http://scrummethodology.com/the-scrummaster-role/
466 9754 [email protected] Sprint Retrospective • Steps 1. Set the Stage 2. Gather Data 3. Generate Insights 4. Decide What to Do 5. Close the Retrospective • See: Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen
466 9754 [email protected] Sprint Retrospective: concrete practice • Hold a retrospective for your mob team • Time period: Sunday, Sep 13, through delivery of your HW2-3 • Hackpads • http://gr8p.pl/gildedmob • http://gr8p.pl/internationalmix • http://gr8p.pl/powermob-gilded • http://gr8p.pl/tonys-mob • 5-10 minutes, then share with whole group
466 9754 [email protected] Sprint Retrospective: concrete practice • Share your highlights of your retrospective • (This is a scaling pattern for collaborating teams.)
466 9754 [email protected] Sprint Retrospective: conclusion • Purpose: Optimize the Scrum Team • Safety, trust • Vary the activities • Keep it positive! • Act on it Image: http://weisbart.com/cookies
466 9754 [email protected] Homework 4 • Part A: due Sep 28 • Perfection Game feedback on tonight’s class: https:// www.surveymonkey.com/r/R5ZJ9Z5 • Create 1 homework question about Agile—any topic we’ve covered so far. Example: What is the purpose of Sprint Planning? • Add your question to this spreadsheet: http://gr8p.pl/asd-hw4 • Email your question and answer to [email protected] • Part B: due Oct 5 before class • Answer 30 crowd-sourced questions about Agile from this list: http://gr8p.pl/asd-hw4 • Suggested reading—see syllabus
rkasper
nro2daisuke
yuyakurodou
ukky86
matsuolab
nbkouhou
ndevaul
masatatsu
jdbedics
theycallmeswift
toco3week
tetsuyaooooo
jscottmo
swwweet
malarkey
philhawksworth
ddemaree
aki_iinuma
chrisshort
jmmastey
kneath
brettharned
pedronauck
addyosmani
kevinliebholz
