role-iq-logo
Rock [Azure]
See all Azure roles

Determining Feasibility and Refining Requirements for Microsoft Azure

With poor requirements, it's possible to have great technical talent and process, and still, produce the wrong product. In this course, we'll gain the knowledge of Agile requirements needed to put your project and your product on the right path.
Course info
Rating
(21)
Level
Intermediate
Updated
Apr 17, 2019
Duration
1h 2m
Table of contents
Description
Course info
Rating
(21)
Level
Intermediate
Updated
Apr 17, 2019
Duration
1h 2m
Description

With poor requirements, it's possible to have top-flight technical talent, and a fantastic process, and produce, fantastically, the wrong product. In this course, Determining Feasibility and Refining Requirements for Microsoft Azure, you will gain the ability to create strong and comprehensible Agile requirements. First, you will learn about User Stories, the atomic unit of Agile work. Next, you will discover the Agile Artifacts that you can use to schedule rationally and answer the question "when will it be done?" Finally, you will explore how to transform your hard-won user stories and acceptance criteria into tests. When you’re finished with this course, you will have the skills and knowledge of Agile requirements needed to put your project, and your product, on the right path.

About the author
About the author

Chris B. Behrens is a writer, speaker and software developer, specializing in DevOps. He has been a developer and architect for more than twenty years focusing on small to medium size companies and the development changes they face.

More from the author
More courses by Chris Behrens
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi everyone! My name is Chris B. Behrens, and welcome to my course, Determining Feasibility and Refining Requirements in Microsoft Azure. I am an independent author and speaker. With poor requirements, it's possible to have top-flight technical talent and a fantastic process and produce fantastically the wrong product. In this course, we're going to explore the nature of software knowledge in Agile and learn how to create strong user stories and not kid ourselves about schedules. Some of the major topics that we will cover include creating great user stories, measuring progress with burnup and burndown charts, three Agile tools for reducing uncertainty, and changing user stories and acceptance criteria into unit tests. By the end of this course, you'll know how to create projects that become more predictable as they progress and how to answer the question, When's this going to be done? Before beginning the course, you should be familiar with software development and good solution architecture. From here, you should feel comfortable diving in to an advanced Agile process and requirements with courses on Advanced Unit Testing and Agile Project Management. I hope you'll join me on this journey to learn how to create strong and comprehensible requirements with the Determining Feasibility and Refining Requirements course at Pluralsight.

Mitigating Risk with Good Requirements
I'm going to continue the shift we made in the last section to feasibility by talking about my preferred methodology on top of Agile, which is called Lean development. Before we dive too deeply, let me make it clear--Lean is Agile. All Lean software development is Agile development, but not all Agile software development is necessarily Lean. Lean development comes from lessons learned from process improvements in manufacturing, from some of the miracles that process pioneer W. Edwards Deming wrought in Japan after World War II, and in particular how the Toyota Production System came to be. In the last module, we talked about burnup charts. Burnup charts give you a plot of your velocity, or sometimes referred to as cadence as well. These charts rely on history. There are several embedded premises here. We have some estimate of the amount of work to be done. And we have some estimate of the velocity, that is, how quickly our team can process the work. If you take these two items together, Work divided by Velocity, you end up with a time dimension--how long the project will take in multiples of the velocity denominator. This all seems very nice, rational, and efficient, but it has a tremendous premise of its own--our estimate of the work is accurate. The fundamental truth we accept with Agile is that it's not. We understand from the outset that the existing requirements will change, new requirements will be added, and requirements will be dropped. In our time estimate, there may be huge landmines that are going to blow up in our face when we hit them in the schedule, and make our time estimate look like wishful thinking, which it is. But what Lean thinking can do for us is to help us find out how wishful as quickly as possible.