[MUSIC] Hi, I'm Ken Wong. Welcome to the Reviews & Metrics for Software Improvements course. Within the Software Product Management specialization. This course is intended to be taken after you've taken the course in Agile Planning for Software Products. This course serves as the arms of the Inukshuk that depicts the structure of our specialization, built atop the body and legs. Suppose you're working on a software product. You've identified a product opportunity, talked to potential users, defined amazing requirements, mapped out the releases, and the developers are designing and implementing the product. Is everything on target? Following Agile, what needs to change? I previously outlined that better software involves three goals: the right product, done right and managed right. But how do you know you're aligned with these goals? Also, how do you improve on your ability to form the right product, while doing and managing it right? For each of these goals you need to deduce the insights for improvements from continuous feedback in specific types of reviews and metrics. There will be a blend of subjective and objective data to analyze when considering improvements to the product itself, the underlying process and the overall project. For the right product, you need to demo it to gain early feedback. You need to observe how users are using the product, and gauge their effectiveness and efficiency. You need to collect data about user satisfaction and signs of the product’s level of success in the market. You use all of this information to identify what to improve in the product's features. Now, for doing the process right, the developers need to review and inspect the work products they create to catch and repair issues early. They need to monitor data regarding important quality factors, like correctness, in terms of defect rates. They use all this information to identify what to improve within the product implementation and what to adjust in their process for the desired quality. For managing the project right, the development team needs to meet briefly each day to update and synchronize with each other. They need to track measurements like velocity. They need to monitor and communicate the completion of planned users stories and tasks so everyone knows what the project status is. They apply all this information to coordinate work and to identify what to improve to complete work more effectively without waste. This course covers several practices to reveal potential product, process and project issues early, regularly and continuously. As issues get resolved, the result is great software that gets better with each iteration. There are four modules in this course. In the first module, Morgan Patzelt will focus on the goal of the right product. She'll discuss more about sprint review meetings where the product is demoed and reviewed to produce feedback. Then she will describe user studies to observe how effective and efficient users are with the product. She'll also outline example measures for product success, and talk about processes used in industry to create successful, well designed products. In the second module, Bradley Poulette will focus on the goal of doing the process right. He will describe peer review techniques done by developers to inspect and improve their work. We'll explain the purpose of metrics, and how they address specific questions that align with goals inherent to the product or process. He will outline desirable properties of useful software metrics, present popular metrics, and finish with a discussion of defect-related metrics. In the third module, Morgan returns to focus on our goal of managing the project right. She'll describe a common Agile practice called the daily scrum, and recap the notion of velocity. She'll detail the release burndown chart used to track completed user stories in successive sprints. She will also describe a task board, and iteration burndown chart to track the completed tasks within a sprint. These practices help you discover whose work is half-done and not effectively brought to a finish. In the fourth module, Bradley returns to talk about retrospectives. A practice to determine lessons learned which can be applied at the end of a sprint or at the end of a project. He'll describe exercises within a project retrospective to identify successes, reveal short comings, revisit what happened, recognize all the contributors, and produce constructive lessons to carry on into future projects. By the end of the course you will have learned an effective set of reflective practices to improve your product, process, and project. This knowledge will help you to create a great software product. The right product, done right and managed right.
