Difference between revisions of "Snowstorm Sprint Retrospective Archive"
Jump to navigation
Jump to search
(5 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{Project Snowstorm Nav}} | |||
__TOC__ | |||
<br clear="all"/> | |||
== | =Snowstorm Sprint 7 Retrospective = | ||
Date: Mon Nov 15, 2010 | |||
=== | == Team Feedback == | ||
=== Merov === | |||
Good: | |||
* Time track work better though we still need to do a better job | |||
* | * Got traction on "big" items, not just bug fixes | ||
* | |||
Needs Improvement: | |||
* | * We're doing a good job with small things but not that good with bigger ones. My own experience shows that 2 weeks is to short to design/socialize/review/code/iterate on anything. | ||
* | * Time and work load not used consistently, so the burn rate and dashboard cannot be trusted. Please update the work spent and remaining time! | ||
* We still need a way to pick patches from community faster | |||
=== | ===Oz === | ||
Good: | |||
* | * group communication worked extremely well | ||
* made lots of progress communicating with community | |||
* handled several integration & beta release minor crises and not have it disrupt everything we’re doing | |||
Needs Improvement: | |||
* | * trouble focusing on coding tasks | ||
* | * time is too fragmented | ||
* need a way to take quick & easy patches - use RB & has proposal for fast path | |||
=== | ===Esbee=== | ||
Esbee had nothing good to say. | |||
Needs Improvement: | |||
* Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.) | |||
* | * On a case by case basis, I think we need to consider creating project branches for stories we pick up so we don't have non-functional code sitting in viewer-development. | ||
* | We can determine this during sprint planning by marking tickets for which we want to create a project viewer. | ||
===Anya=== | |||
* beginning of sprint - not enough work - end of sprint - not enough time | |||
* | |||
===Resident Feedback=== | |||
Boroondas Gupte: Where communication went a bit wrong (I'm partly to blame about that myself, I guess) is VWR-23826 . WolfPup asked me to test the STORM-102 branch, where I noticed that. I've asked Oz what info would be needed from me to fix this before it hits viewer-dev, but I still don't know what I have to provide. | |||
* | * this issue is not lost and will be included in the next sprint. | ||
== | ==Improvement & action plan:== | ||
===3-week sprint=== | |||
* doing things in the open takes more time | |||
* Sprint 8 will be a 3-week sprint. At the end we will review and consider whether to keep this going forward. | |||
* still need to stagger design & socialization work so we have enough at the beginning of a sprint | |||
===Update dashboard daily so we can use results=== | |||
* give ourselves credit for what we do, and give ourselves data for better analysis. | |||
* grumpity to follow up personal tracking in jira | |||
* add merge monkey task in jira and assign back & forth during sprint | |||
* beta build task | |||
* best practices sharing. | |||
* oz to propose a proposal for quick updates | |||
= | ===Project viewer for larger changes=== | ||
* named branch in a forked repo? Fork? | |||
* | * project viewer before merging back into viewer-dev | ||
* | ** code review | ||
** product owner review | |||
== | = Past Retrospectives = | ||
[[Snowstorm_Sprint_Retrospective_Sprint_2 | Sprint 2]] | |||
Latest revision as of 15:15, 15 November 2010
Snowstorm Sprint 7 Retrospective
Date: Mon Nov 15, 2010
Team Feedback
Merov
Good:
- Time track work better though we still need to do a better job
- Got traction on "big" items, not just bug fixes
Needs Improvement:
- We're doing a good job with small things but not that good with bigger ones. My own experience shows that 2 weeks is to short to design/socialize/review/code/iterate on anything.
- Time and work load not used consistently, so the burn rate and dashboard cannot be trusted. Please update the work spent and remaining time!
- We still need a way to pick patches from community faster
Oz
Good:
- group communication worked extremely well
- made lots of progress communicating with community
- handled several integration & beta release minor crises and not have it disrupt everything we’re doing
Needs Improvement:
- trouble focusing on coding tasks
- time is too fragmented
- need a way to take quick & easy patches - use RB & has proposal for fast path
Esbee
Esbee had nothing good to say.
Needs Improvement:
- Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.)
- On a case by case basis, I think we need to consider creating project branches for stories we pick up so we don't have non-functional code sitting in viewer-development.
We can determine this during sprint planning by marking tickets for which we want to create a project viewer.
Anya
- beginning of sprint - not enough work - end of sprint - not enough time
Resident Feedback
Boroondas Gupte: Where communication went a bit wrong (I'm partly to blame about that myself, I guess) is VWR-23826 . WolfPup asked me to test the STORM-102 branch, where I noticed that. I've asked Oz what info would be needed from me to fix this before it hits viewer-dev, but I still don't know what I have to provide.
- this issue is not lost and will be included in the next sprint.
Improvement & action plan:
3-week sprint
- doing things in the open takes more time
- Sprint 8 will be a 3-week sprint. At the end we will review and consider whether to keep this going forward.
- still need to stagger design & socialization work so we have enough at the beginning of a sprint
Update dashboard daily so we can use results
- give ourselves credit for what we do, and give ourselves data for better analysis.
- grumpity to follow up personal tracking in jira
- add merge monkey task in jira and assign back & forth during sprint
- beta build task
- best practices sharing.
- oz to propose a proposal for quick updates
Project viewer for larger changes
- named branch in a forked repo? Fork?
- project viewer before merging back into viewer-dev
- code review
- product owner review