Begin forwarded message:
Monday, October 9, 2017
Friday, October 6, 2017
Initiator: Beth Galambos, PO, Healthesystems
Participants: Ryan Dorrell, Isa Jelez, Marilyn Brislin, Kate Leonardo, Bill Somerville, Sherrie Hanrahan, Patrick McClain, Liliana Talice, Prachi, Gordon Ridge, Riccardo Reimers, Ruchir Shah, Linda Cook, Bashanth Prasannathiotha
- High/medium/low confidence on estimates
- Seen by business as 'scientific'
- Minimal business increment (MBI)
- What MUST go out the door to be value to the user
- Why even bother with estimating?
- Dev teams debating point values
- Teams may overestimate if there is a penalty for being 'wrong' in their estimates
- They have to learn, especially if coming from a waterfall environment
- Fixed vs variable outcome deliveries
- Fixed - more time estimating
- Variable - less valuable estimating
- Larger efforts not focusing on risk and project management, but should
- Customer education is important because some think that it's about 'more and faster'
- What it's really about is eliminating waste
- Who gets involved with estimating?
- Whole team, part of team?
- High level - representatives of the team
- Detailed - the whole team
- Retrospecting on stories' estimates
- How did we do on that estimate now that the work is done?
- Anchor stories - bring a 3 pointer and 5 pointer to refinement/planning and point all stories compared in size to the anchor stories
- Kanban - try using a mean or average point value for every story. Do this if you have data to support it.
at 3:48:00 PM
Initiator: Prashanth Prasannathirtha
Participants: Kevin Krieger, Suzanne Layne
What metrics are easy to produce and valuable to key stakeholders?
- story points per sprint - this helps product owner to understand capacity of team and helps in future planning
- Number of support hours spent by the team - This helps to understand the average time spent by team for support activities and provides inputs for sprint planning
- number of releases per time period - this shows how quickly team can release features to production
- sprint burn down charts - helps team to understand their progress. Not for management reporting
- release burn up charts - in case of projects, this kind of chart shows the progress at end of each sprint. Helps to understand the overall health.
Additional discussion points
- Comparing velocity across teams is not needed as velocity is specific to a team.
- defects in non-prod environment is not relevant to end user
- if you have long running teams, the is better awareness of team's capacity and better trust between PO and teams. This will eliminate need for lot of metrics.
- automation helps you to improve predictability and reduces manual metrics
- some of the tools generates reports automatically
Ideas for Action/Next Steps:
at 3:40:00 PM