I’m a big fan of time driven delivery. You can read about it in several other posts. Especially early in the project, where nobody feels like making a tangible build at all, because there is not so much to build. I keep stressing to get into the habit of delivering, because time never ceases to be perfectly reliable, while units of work and estimates always fail.
Later in the project, when you are accustomed to making builds and to actually ship, you can let go a bit. Plan the next build around the time you estimate you can deliver a complete feature or set of features.
Don’t let go too far though, because there is this little voice in your head, that wants you to finish a lot of things before actually making a build. It wants you to go for perfect and there is the risk of loosing your habit of delivering often. If you need a guideline, never wait more than 2 weeks before making the next build.
Great post.I encourage all of the tertess in my group to code, on project work, test automation, and tool creation, or even personal projects. In my own experience, knowing how to code and how software is built helps me to test it I know what areas are more likely to have problems and I’m able to work with the devs to prevent issues before they make it into the build. A balanced set of skills is great to have.