Design / UX Team Meeting
When: October 9, 2007
Conference Code: 350
Allison, Eli, Shaw-Han, Gary, Daphne
We discussed the value of having a daily stand-up meeting and how those relate to the current daily stand-ups. The decision was to continue with the current stand-ups, and not have a separate design stand-up.
Monthly placeholder meetings for planning and show & tells will be scheduled. We recognized that show & tells won't always be necessary but having the placeholder will open the time and encourage design review.
Monthly Meetings - we still need to decide on the timing of these.
- Planning & status
- Show & Tell Presentations
Everyone seemed to agree that the idea of an agile planning game makes sense for the design team. We'll continue talking about what this looks like over the next few weeks.
The plan is to use jira for our status board. We'll track design activities there. For this week, we can use confluence to begin making our lists of design activities while we get jira set up with a design category.
- Everyone create design tasks and add them to the working page,
- We want to capture all activities we currently know about
- Activities scheduled soon will be more fleshed our and granular than activities happening further out.
- Shaw-Han will talk to Michelle or Anastasia to get jira set up for us
- Daphne will send out case study on the planning game to help make it more concrete for folks
Follow up on Summit Work
Lots of discussion about the confluence pages and transcription of work from last week along with further fleshing out.
- Gary will do some reorganization based on the discussion
- Daphne will add high level categories to the problem space pages
We discussed several approaches to getting to components and getting some prioritization done so we can move work forward. The decision was that we don't need to be too scientific. We have done some prioritization of the problem spaces and know each of the 4 that were fleshed out at the meeting are important. Working groups are fleshing out components within their problem spaces. We'll discuss those components next week and come up with some priority -- top 10 list perhaps -- so we know the next ones to focus on. Some criteria we discussed that will play into decision: relationship to other local work, amount of design & development effort -- we'll want to choose some components that are "design light" so development can get started. In parallel we'll be working on the design of other components that may take more design time up front.
Question that came up: Who is/are the development team(s)?