Monthly Archives: February 2016

Sprint Retrospective Meeting

• After Sprint Review, prior to next Sprint Planning Meeting, Scrum Team inspects itself and creates improvement plan • Time boxed: 3 hours/1-month Sprint Purpose o How last sprint went with regards to people, relationships, process, tools o Items that went well and potential improvements o Create improvement plan Update definition of ‘done’ i.e. signing… Continue reading »

Daily Scrum Meetings

Benefits • Eliminate other meetings • Identify and remove impediments • Promote quick decision making, acknowledgments and agreements then and there • Improve communication and knowledge across the board • Dev Team assesses progress towards Sprint Goal • Complex issues taken off-line • 15-30 min time-box, same place and time every day • Not a… Continue reading »

Sprint Planning Meeting

• Meeting to plan work in next Sprint • Plan created by entire Scrum Team • Time boxed (8h/1month Sprint) – proportional for shorter Sprint Goal • Short statement and objective of sprint • Gives Team some flexibility on functionality/method • If work required is different than expected, Team work with Product Owner to negotiate… Continue reading »

Product Backlog

Contains • Ordered & estimated list • Orderable by ‘value’, ‘size’, ‘risk’, ‘dependencies’, etc. • Covers features, requirements, enhancements, fixes • Never complete, baselined nor signed-off • Items have nontechnical description • Top list items more fine grained than the ones lower down Accountability • Product Owner owns the Product Backlog • Team responsible for… Continue reading »

Scrum Team

Product Owner (PO) owns Product Backlog – Drives – up to date knowledge of scope – Clear goal, communicates product vision – Maintains Product Backlog – Regularly updated with new intel, circulating intel accordingly – Collaborates with Scrum Team and Stakeholders – Understand requirements and identify solutions (or route to solutions) – Must participate in… Continue reading »

The Sprint

Protected time-box or one month or less (2 weeks most common) Aiming: • Consistent durations • Deliver increment in functionality/milestones Sprint is scheduled whilst considering: • Limit change, complexity, risk • Increase predictability Changes within Sprints: • None • Scope may be clarified and re-negotiated as more is learned • Product owner cannot force it onto… Continue reading »