Each of the use cases defined as part of our use case names post is described at a high level of detail here. The goal is to get a broad view of the domain for our project so that we can focus on the most important elements. This is a key step in using use cases in an agile project. We need to understand enough of the big picture in order to determine what is actually the most important. Then we will work on the more important use cases.
Continue reading APR: Use Case Briefs
In our agile programming case study, we have two corporate goals, but one of them (learn Ruby on Rails) only drives constraints, not requirements. The other goal is to make it easier for people to find and read great content in our niche. This makes the documentation of goal-driven use cases pretty straightforward. All of the use cases support this single goal.
With an understanding of the goals, the next step is to define the use case names.
Continue reading APR: Use Case Names
The last step in our agile software development project was documenting our understanding of our users. In this article, we will define the personas that we will use to guide our design and requirement development. This definition of personas is built by combining our experiences in consulting, product and program management, and business analysis.
A couple other good articles on how to create personas:
In this article we define our primary, secondary, and supplemental user personas.
Continue reading APR: Persona Development
In the discussion on our article about understanding users as part of our agile software development case study, Rolf raised an interesting question about the scope and vision of having people rate articles:
I’m wondering what an ‘article’ is. Does it have characteristics? Is it just some piece of knowledge (I’d say: yes), or even just a reference to a piece of knowledge?
Is it important that an article is readily accessible from the site (that would exclude training courses, books, …)? My answer: no, even a hint for a good book or a reputed company would be of help to the personas.
This article has a poll asking for your inputs. Continue reading APR: Scope and Vision – Vote On It
Continuing the articles in our agile project case study.
The next step in our agile requirements management process is to develop an understanding of our target users. We believe a user-centric design approach is important. The user interface should conform to the way our users think about what they are doing and trying to accomplish. We should minimize the amount that we force our users to think like our software, and maximize the amount that we should force our software to work the way people want it to.
In this article we document some of the thoughts around who are target users are, and how we think about finding patterns in the way that they would approach using our product. This is a micro-example of market definition / segmentation. We’re looking for patterns that provide interesting commonalities. We’ll use this as a foundation for developing personas.
Continue reading APR: Understanding Our Users
Corporate Goals for the Product
We have two corporate goals for our agile project. One of them directly drives the features and functionality, and the other one is a driver of a constraint on the implementation approach. Both types of goal are relevant.
A process that relies on structured requirements always starts with goal definition. Even if we are combining principals of interaction design with structured requirements, we still need to understand our corporate goals. It is from this understanding of goals that we can move forward to developing a contextually relevant understanding of our users.
Continue reading APR: Corporate Goals
To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.
But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.
These two project management artifacts seem logical to combine into a single article
Continue reading APR: Scope and Vision
This is an administrative post, to help organize the articles in our agile software development experiment. The feedback has been positive so far, so here we go…
Continue reading Agile Project: Ratings – Administrivia
We’re considering trying an experiment in agile software development at Tyner Blain. There aren’t (m)any examples of agile software development that we can watch and study that include agile requirements development. Many people still think that agility and requirements management are mutually exclusive.
If the responses to this post don’t overwhelmingly request that we not do it, we’re going to develop a website/product for Tyner Blain over the next short period of time – and write about it as we go. You’ll see the steps as they happen, watch mistakes and even help fix them. You’ll be able to provide prioritization inputs and feedback as the project evolves.
Read on to find the details of the idea, and how we we’ll approach the project.
Continue reading Agile Software Development Experiment