Rodney discussed EMACS org mode – after some discussion of the relative merits of EMACS vs Vim vs inferior other editors. It essentially allows you to edit bullet points, but it can be used for calendars, todo lists, estimates, and so on. Via a keypress, you can add templates for a todo item, including schedules and other metadata, and include it in your todo list. This metadata is used in the display – e.g. you can display an agenda for the day, which will include all of the tasks scheduled for today. You can mark those tasks as done once complete. Tasks can also be split into a hierarchy of tasks, and the top task can display a percentage of the remaining tasks under it. It also has time tracking – once you start a task, you can start time tracking, and then it will be logged against that task.
Advantages of it are – it’s simple, it’s fast, it’s free, and it’s text based so other tools will work with it.
To achieve similar results, Chris uses todo.txt – which is essentially a text file in Dropbox, but it’s supplemented by command-line tools, and a phone app. Because it’s backed by a text file, then you can always access your data anywhere without any other tools. Reece uses a text file in Vim. Inigo used to use a text file in Vim, but now uses Trello.
We then discussed tea making. There was no consensus reached.
Stephen then talked about sprint planning. In various of our projects, we are doing sprint planning in different ways. The default Agile approach is to start with a demo of the work done in the previous sprint, then a retrospective of the previous sprint, then the project owner provides the things that they would like to be done in the sprint, and the project team discusses which ones can be done in the sprint. In one of our projects, we have a looser sprint planning, that doesn’t involve prior discussion of the statistics from previous sprints, and not much backlog grooming. We discussed the merits of estimation – even though the results of the estimation are not always useful, the process of doing estimation and giving developers a good idea of how long tasks are expected to take is useful. We also discussed prioritization, and how new tasks should be dealt with – whether they should be completely rejected until the end of the sprint, or whether they should be prioritized against exising tasks. We agreed that we would look at more explicit prioritization in some projects. We also agreed to combine some brief explicit estimation of tasks in the sprint planning meetings, with announcing on Slack a brief description of the task and how we would approach it and how long it would take.