Welp, this one’s a full day late, but I’ll be writing the post for today right after this one so I’ll be back on schedule.
Tuesday, May 13
We started the second day of the exercise course talking about planning and estimating. Planning and estimation is the stage in Scrum where you estimate the required resources for a project (time, money, and talent) and how much you can do in one iteration. We leaned about using estimation units, which are used to estimate the size of just about anything (features, task, etc.) in terms of whatever measurement may be relevant (e.g. difficulty, time needed). To help learn this process the groups went through an exercise where each group estimated the size of various dogs using Planning Poker. Finally we learned about prioritization and various progress-tracking artifacts. Prioritization can be achieved through a value/risk matrix. Progress tracking usually involves a Scrum board (which tracks task completion), a Burn-down chart (which tracks sprint completion), and a Burn-up chart (which tracks project completion). One other tracked measurement is velocity, which is how much effort has been handled in each sprint.
The final chapters of the course were Requirements, QA, and Development. Generally, requirements can be put into one of three categories (Functional, Non-functional, and Business Rules), and are made up of Use Cases, which are broken down into Scenarios, which are then broken into tasks. We were given a new project for the next exercise, which was to come up with 10 functional and 3 non-functional requirements. In Agile, QA and development are all about TDD. Acceptance is defined, tests are written, and then code is written. The QA person helps add and define user stories and acceptance criteria while also helping build tests and building some tests themselves. For the second part of the exercise we spent a short time creating acceptance criteria for 3 of our requirements. Developers focus on priority, building things right, using TDD and continuous integration, and finishing each sprint with a shippable product. Other than some miscellany the development chapter was the final one of the course. I learned a great deal about Scrum in these two days, and I hope I can retain at least most of it to use in the upcoming sprints we’ll be doing in the boot camp.
I spent way too long on this post as well; I think it keeps happening because I’m still not sure exactly what to post about other than just summarizing my day (and there’s so much to summarize).
Some Thoughts on Overthinking 