![]() If something might not be technically doable, such as sending a man to space with warp drive system based on dilithium crystals, or doubling the effective range of blue-tooth, then that’s research and has to be expensed. Likewise with defects - it’s a very different type of work than normal story development.ĬAPITALIZATION ADDENDUM: Generally, spikes should be capitalizable. It’s very difficult to correctly relatively compare to a 1 point story a spike that is time-boxed in terms of hours or days. Defects and spikes are estimated differently than how we estimate stories (relative to each other). I choose my poison of NOT including spikes in my velocity. Therefore, whether you do all of your spikes in Sprint 0 or spread them out over the course of a release, I don’t want them hanging around a long time and as for defects, I don’t estimate them. For example, one team’s policy was that all spikes must be completed in 12 hours or less, each must have one explicit question to answer, we must know who the answer goes to, and there must be a “demo”. So, setting a small time-box limit for them is another way to encourage clarity. Sometimes we get lazy, especially for spikes. But estimating doesn’t always achieve that clarity. Being clear about the work, the goal, and the acceptance criteria is just as important for spikes as it is for user stories. Estimating can help us clarify our acceptance criteria. One great benefit we get from estimating user stories is that estimating drives clarity about the work. It’s about not having a big backlog of unresolved spikes, just like for defects. It’s about resolving them quickly just like I would want to do for defects. I may have planned stories for the next 4 months, but I don’t want a backlog of spikes that I can’t implement in the next 2 sprints. I rarely consider them planned work of the same order as stories. Therefore, for me, spikes don’t stay in the backlog very long. And in that case, I still want to execute them ASAP. However, spikes do come along later in our releases as unplanned work. (I’m assuming periodic releases - Prioritizing spikes in the face of continuous planning and continuous deployment is another story.) For these reasons, we want to knock out spikes early each release. They often correspond to un-estimated user stories and stories with ambiguity - stories where we need to do a research spike before we can estimate. Choosing Not to Do All of Your Spikes in Sprint Zero For those, don’t estimate them for the same reason I don’t estimate defects. When computing your average velocity and when release planning, you can exclude Sprint 0s or HIP Sprints - don’t count them in the divisor when averaging your velocity don’ t allocate points to them when release planning.Įven if you do all of your spikes in Sprint 0, additional spikes often come along during the release. If you don’t estimate spikes, your Sprint 0s or HIP Sprints may have no points.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |