Talk:WMF product development process/Proposal
Thank you for creating this :) CLs have a goal to build out a toolkit that support's communities' and product teams in collaboration with one another as well; not sure how it can work within this page; if not, we'll figure something out. -Rdicerb (WMF) (talk) 22:52, 30 September 2015 (UTC)
For starters, my deepest apologies if I am committing a major faux pas by moving the Timeboxing segment to a sub-segment of this section, but (perhaps coming from my limited perspective) I see Prioritization as major pieces in both deciding what to build, and deciding when to build it, both in terms of overall products (VE) and around individual features built within product (Citoid within VE). I have been thinking about prioritization against a series of questions which balance impact, risk, requests, and feasibility. Maybe it's more philosophy than process, but I have been thinking about it this way:
- Does it align with the mission and vision?
- Is it feasible? Are there blockers?
- Has it been requested?
- Does it fill our most pressing needs/create the greatest opportunity for impact?
"Timeboxing is a prioritization technique"
I'm not sure I would call it a prioritization technique. To me, it's more of a release management technique. The tasks have already been prioritized before they went into the timebox (or feature box). It's not a huge deal, but as I was reading I was interrupted by a statement I disagree with. Maybe the phrase could just be removed, and describe what timboxing is, rather than starting with what type of thing it is (or isn't). --KSmith (WMF) (talk) 20:21, 9 October 2015 (UTC)
- I wonder if this concept is used against, say, an overall product. Is it possible that it's a release management technique when solely used against sprints? -Rdicerb (WMF) (talk) 22:57, 12 October 2015 (UTC)
I would like this section to come across with a bit stronger agile slant, and to look less like it is promoting waterfall. Even with (or especially with) a 2-year project, I would definitely want to see multiple releases. Those releases might only go to limited (and/or internal) audiences, but avoiding a "big bang" release is a core part of agile. This section as written doesn't preclude an iterative release approach, but it should probably encourage one. I think it's important to have it in this section, rather than waiting for the "milestones" section.--KSmith (WMF) (talk) 20:33, 9 October 2015 (UTC)
- Agreed here. For Phase Model Scales, I think greater definition or differentiation is needed for "Develop" and "Release". Because we develop in the open, developers can watch projects while in Alpha. Once a project goes into Beta, any user with access to Beta features can access and try it. These might be considered "release" which would reduce the time frame in that slide. -Rdicerb (WMF) (talk) 23:34, 12 October 2015 (UTC)
This didn't make sense to me at first, because I view a milestone as (by definition) entirely specific to a particular product at a particular time. I think this is saying that a class of milestone can be turned into a form of template, and that milestone template can be reused. I'm not sure what a "bundle" is here. --KSmith (WMF) (talk) 20:33, 9 October 2015 (UTC)
Milestones and Scrum
Milestones are not an inherent part of Scrum, and to a small degree, run counter to its main philosophy. I would be happy if "milestones are used in the product backlog" changed to "milestones can be used in the product backlog", and then adding a sentence such as "Milestones in the product backlog represent best thinking at a given time, and are likely to shift (often dramatically) over time." --KSmith (WMF) (talk) 20:33, 9 October 2015 (UTC)