You can’t move for people talking about the project to product journey lately. Getting organisations to start mapping out what their products are so they can build cross-functional teams around them. Projects are transitory and lose us all of the learning, we want long-lived squads! While these sentiments are all rock-solid, unfortunately, they’re missing the point. I’m going to be controversial and say that creating a product team simply isn’t good enough. What you actually need is outcome alignment.Continue reading “A product team is not the answer”
All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers. For a Scrum overview, please see Agile Overview. This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.
At project initiation, the team will meet in order to determine the themes and goals of the project. In determining these themes, many factors will need to be considered. These themes will also need to be estimated and prioritised so that the development team knows what to build. These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done. The owner will determine the themes, but the developers will aid in this choice. Developers can help this decision by indicating the risk level or dependencies of each theme. These themes are often written on Index cards and should be considered at a high level of abstraction, such as:
- As a user, I require the ability to add new cars so that I can manage my growing stock.
- As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
- As a user, I want the software to record my high scores so that I can try and beat other scores.
Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.