1. what went well
1.1. deployment went well
1.2. Grunt setup
1.2.1. made theming and css splitting much easer
1.3. workflow
1.3.1. Completing tasks in one flow was effective
1.3.2. much more effective for improving our testing
1.3.3. can get an overview of project status at any point
1.3.4. left more dedicated time for maintenance tasks
1.3.5. points
1.3.6. no stress
1.4. task detail
1.4.1. more time
1.5. QA
1.5.1. we found some bugs in the FAQ early
1.5.2. we reviewed tasks much earlier, even before testing
1.6. documentation
2. what could be improved
2.1. anthony
2.1.1. Anticipation on resource availability
2.1.1.1. Personal circumstances got in the way
2.1.2. Widget 20 had to be rebuilt
2.1.2.1. unusual bugs
2.2. seth
2.2.1. workflow
2.2.1.1. not everyone was following our flow very well
2.3. Robert
2.3.1. user flow planning
2.3.1.1. should have been done earlier
2.3.1.2. set up a checklist for starting
2.4. Blockers need to be dealt with faster
2.5. personal circumstances get in the way of being efficient
2.6. prodpad details have been missing in a few places
2.6.1. some stories made no sense
2.7. how do we start tasks
2.8. how we get involved in testing
2.8.1. we need to get developers involved in testing
2.8.2. we don't have shared knowledge about how testing works
2.9. Testing is centralised
2.10. core hours could be improved
3. proposals
3.1. transparency about availabilabily
3.1.1. If possible, send an email to [email protected] when you are not available in core hours
3.1.2. If you cannot email, send a text 3 people if you cant make it
3.2. Online status for core hours
3.2.1. Hipchat should show your current availability. If you know that you will be away please leave a note in your status
3.2.1.1. sometimes this will be an issue with bandwidth
3.2.1.2. issues
3.2.1.2.1. This is a duplicate of a a status note
3.2.1.2.2. We are available by default
3.2.1.2.3. Why make things more complex and more confused
3.2.1.3. Objections
3.2.1.3.1. Unnecessary complication
3.3. beer points
3.3.1. beer points assigned when you are late for scrum. One minute late for scrum. More than five minutes late is 2 beer points. Unless you have provided a valid reason.
3.3.1.1. On the dashboards
3.4. time logging in real time
3.4.1. Jira time logging should take place in real time. Don't batch the time at the end of the day.
3.4.1.1. There is a Mac app called Bee that integrates with BEE
3.4.1.1.1. try to use it if you can.
3.4.1.1.2. may not be able to work offline
3.4.1.2. BEE is not available on windows
3.4.1.3. Sometimes we have to jump around multiple tasks. It can be difficult to reliably keep track.
3.5. Acceptance criteria validation
3.5.1. Before starting a task, any developer should understand how to test the details of their tasks. The developer, product owner and tester must work together to make sure that they are building the right thing before we start. Use user flow diagrams where necessary because they help us understand the things we are testing.
3.5.1.1. There will be an impact on productivity
3.5.1.2. Pete will organise a workshop to teach this
3.5.1.3. Do not make up the business case for the client.
4. the future
4.1. Analytics
4.1.1. How are we going to measure our goals?
4.1.2. How do we plan things for many months in advance
4.1.3. A/B testing
4.2. Real prototyping
4.3. Learning and measuring
4.4. Peer contracts
4.4.1. clear ideas of what we expect from each other
4.5. better ability to measure business value
4.5.1. How do we let the client see this
4.6. better scheduling of followup work
4.6.1. better post delivery refinement
4.6.2. What happens in three months time
4.7. devops
4.7.1. we dont have what we need on the devops side
4.7.2. Continuous integration
4.7.3. Virtual machines
4.7.3.1. better dev environment setup
4.8. get rid of Pete
4.9. varied work
4.9.1. multiple clients
4.10. end to end linking of end feature to original idea
4.10.1. How do we link documentation to actual tasks
4.10.2. tagging from idea to documentation