[00:01:13] instead, it goes off of date created. I'm not 100% confident I follow the code, but thanks to the comment "If a task was opened in the past but added to the project recently, it is counted on the day it was opened, not the day it was categorized.", I'm 99% sure [00:01:38] so we should make sure that Phragile's burnup is not in any way based on this approach [00:02:26] because it will give the wrong answers to questions like, "as of Tuesday, March 31, what was the total value of all open stories in Sprint 15" [16:27:29] jaufrecht: right. both phab and phrag currently use "data as of today", which is not what we want. The phragile folks are aware that (for the release burnup at least), we need to reconstruct history [16:28:52] ggellerman____: (or anyone else) Do you have a definition of "batch size" handy? I'm having trouble finding one, and I need to define it as a segue into WIP [16:29:02] It's more than that - the default burnup in Phabricator does do historical reconstruction, but in a very simple way that will produce incorrect data on the burnup. I'm flagging this as something to watch for, that the Phragile approach doesn't repeat the mistake. [16:30:06] Roughly speaking, the Phabricator reconstruction takes some shortcuts. [16:30:56] ah ok. They did kind of a "cheapo" history-ish reconstruction-ish. Yeah, phragile knows to build from transactions. But I'll double-check the requirements to make sure it's super clear. thanks. [16:33:23] Phabricator also builds from transactions, but with shortcuts. Specifically, it doesn't actually reconstruct the whole day-by-day history by playing back the full transaction log. Instead, it just cherry-picks certain transactions. But (and this is the example given in the code; the engineers knew about and documented this shortcut and its limits), if you [16:33:23] open a Task on May 1, and then assign it to your project on May 5, [16:33:38] that Task will show up in the chart on May 1, not May 5. [16:34:22] tl;dr: A proper historical report must play back the entire (relevant) transaction log and take a snapshot every day, not just try to query through the transaction log and be clever/quick. [16:35:02] yup, got it. [16:35:38] I'm just going on about it because I spent most of yesterday (with much help) just getting a local copy of Phab up and running, so I want to feel like I got my money's worth [16:36:01] :D [16:42:36] meeple27: "The batch size is the unit at which work-products move between stages in a development process. For software, the easiest batch to see is code. Every time an engineer checks in code, they are batching a certain amount of work" <---Eric Ries [16:42:57] thx! [16:43:40] Could you consider all WIP in each stage a batch? all work waiting for testing, all work waiting for deployment to a staging server, etc? [16:44:27] Open Kanban says (and I have read this elsewhere): "Limiting WIP is a consequence of reducing the batch size of your efforts, and not the other way around." [16:45:14] I view a scrum sprint as being a batch, but I don't view all the WIP in the "In progress" column as being a single batch [16:45:47] (assuming individual tasks can move from in progress to the next column) [16:59:19] so WIP is the list of all work that has been started for a particular stage but not finished [17:00:16] which is purely descriptive [17:00:23] whereas batch size has a more normative or intentional definition? [17:56:29] I think each task is really a batch [17:56:34] which leads me to think that: [17:57:02] "Reduce batch size" and "Limit WIP" are both things you can do to achieve the real goal, which is "Deliver stuff to the next phase frequently" [17:57:38] shoot...I wanted ggellerman to hear that [17:59:19] One whole branch of theory that we haven't broken into, and I haven't seen much in the "literature", is how exactly process improvements help development. How exactly does limiting WIP improve productivity? One way is that having four tasks open at once and jumping between the four may take one developer more time than if that developer did each task one [17:59:19] at a time [17:59:35] i.e., reducing the amount of time spent switching context [18:00:27] other biggies seem to be, reducing time spent doing work that's going to be thrown out (duplicative or unneeded or just bad); reducing time spent on inefficient work; etc [18:01:54] I don't want to go to far down this anytime soon, but it's a helpful piece of the overall model of process change to have in mind as we poke at stuff: what is the exact mechanism by which we think a process change will improve productivity, quality, etc? [18:03:29] right. as a developer, very small stories/tasks really helped me. micro commits absolutely improved my productivity (which is at a level below what kanban or scrum address) [18:04:23] very often we would split a story, let's say from 3 days into 5 smaller pieces. And then 2-3 of those pieces would get done, and the others would not get done...ever...and that was fine, because it turns out they weren't that important [18:04:57] I think a lot of bells and whistles (aka waste) get packed into stories, which should really be split apart (personal pet peeve) [21:17:10] Team-Practices: EPIC: Complete TPG Glossary - https://phabricator.wikimedia.org/T99953#1302577 (JAufrecht) NEW [21:17:23] Team-Practices: [EPIC] Complete TPG Glossary - https://phabricator.wikimedia.org/T99953#1302584 (JAufrecht) [21:42:08] Team-Practices: [EPIC] Complete TPG Glossary - https://phabricator.wikimedia.org/T99953#1302643 (ggellerman) p:Triage>Low [21:43:02] Team-Practices: Get regular traffic reports on TPG pages - https://phabricator.wikimedia.org/T99815#1302650 (ggellerman) p:Triage>Low [21:44:57] Team-Practices: Document Best Practices for tracking and working with Epics - https://phabricator.wikimedia.org/T99956#1302609 (JAufrecht) [21:46:54] Team-Practices: Prepare a presentation on software methodology and TPG's approach and services - https://phabricator.wikimedia.org/T99559#1302664 (ggellerman) p:Triage>Normal [21:50:45] Team-Practices: 2nd pass on bookshelf/reading list - https://phabricator.wikimedia.org/T94475#1302678 (JAufrecht) Rapid Development (McConnell) Software Estimation (McConnell) [21:51:41] Team-Practices: Write blogpost on AnEng decision to move from Scrum to Kanban and experience with Kanban - https://phabricator.wikimedia.org/T99142#1302681 (ggellerman) p:Triage>Normal [21:52:02] Team-Practices: Give a TPG response to T99143 - https://phabricator.wikimedia.org/T99959#1302683 (ksmith) NEW [21:53:19] Team-Practices, Phabricator, Research-and-Data, ECT-May-2015: Migration of Research & Data to Phabricator - https://phabricator.wikimedia.org/T826#1302698 (ggellerman) [21:58:13] Team-Practices: Triage tasks in Radar column - https://phabricator.wikimedia.org/T99960#1302715 (ggellerman) NEW [21:58:41] Team-Practices: Triage tasks in Radar column - https://phabricator.wikimedia.org/T99960#1302724 (ksmith) [21:58:45] Team-Practices: Triage tasks in Radar column - https://phabricator.wikimedia.org/T99960#1302726 (ggellerman) [22:00:21] Team-Practices: Triage tasks in Radar column - https://phabricator.wikimedia.org/T99960#1302732 (ksmith) [23:33:49] Team-Practices, Phabricator, WMF-Design: Migration of the Design team to Phabricator - https://phabricator.wikimedia.org/T832#1302895 (aripstra)