Agile

This post is a slightly updated version of the one published earlier. It was created by Peter Stevens who have later written a whole e-book on Agile Contracts As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project? ...

This post is a slightly updated version of the one published earlier Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization. However, being agile doesn’t mean having no clue on when the work is going to be completed. Vise versa most if not all of the agile methods continuously provide team the current “best guess” on the remaining workload and possibly even options to cut some corners. ...

This post is a slightly updated version of the one published earlier Product backlog always lists items adding value for the customer. It includes functional requirements and non-functional requirements. It can also include items required by the team, but only the ones that will eventually bring value to the customer, e.g. taking into use a continuous integration server in order to guarantee the continuous end product quality. Product backlog cannot include concrete low level tasks and requests for building the intermediate artifacts. For example, it cannot include request for producing the design document unless customer has to ship it further for some purpose. Product backlog utilizes the simplest and the most effective way for prioritizing requests - a simple list. Such a method does not allow for having 100 absolute max priority features and forces the product owner to actually make decisions about the feature priorities. The higher the items are located on the product backlog, the more detailed they are. Items for the closest couple of months are usually quite detailed, while items that will be worked on in some 6-12 month can be defined very broadly and imprecisely. When there are several interdependent teams in the company or department, typically they all have a single product backlog and pull their work from it. Product backlog does not typically include the detailed requirement information. Usually the final requirement details are figured out with the help of the customer, when the requirement is being implemented. Ease of use, clear and transparent purpose is what makes the product backlog so useful for seeing into the project status. ...

Want to try handling your Scrum product backlog in just Excel? Here is a template with lots of comments and a video on how to use it. SimpleProductBacklog.xls ...