1. AGILE AND ME a story with just enough documentation
2. A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department.
3. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
4. ? While agile was taking hold of development, design was still back in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
17. Feature a - stories & tests User stories state the feature’s user needs and the business benefits. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
18. Feature a - Workflow diagram Workflows diagram the end-to-end flow for the feature. If a section of the flow is out of scope for the current iteration or for this feature but needs to be in the flow for clarity, include it in the diagram but note that it’s out of scope for this iteration.
19. feature a - ANNOTATED WIREFRAMES Annotations note behavior of various elements on the page.
20. feature a - functional specs Functional specs describe how a feature will work and are written entirely from the user’s perspective. Functional specs only describe the work for that iteration
A typical waterfall project produces page after page documenting the end-to-end requirements for the entire project -- not for the phase or for the iteration but for the entire project. All of this work, of course, is done in a silo with only the most cursory involvement with development.
Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery “good luck!”, the silos are once again inhabited and silence is golden.
Whether the application is being implemented as designed is the big mystery until the final unveiling n months later. Unless you are one of those fortunate designers who’s embedded in a development team and is, therefore, accessible for questions. But those types were rare.
While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
A great idea, I thought. But first I need to look into exactly what is it about Agile teams that makes them tick. And how can that translate to design.
Well, the individuals with overlapping skills idea ties in with Tim Brown’s T-shaped people. Actually, it suits it to a “T” (ahem). And designers, like developers, are rarely one-dimensional and like flexing their creative muscles.
So, blending Agile and UxD means we’re still using the same tools (task flows, wireframes, etc.) but we’re no longer separated from other team members and we’re designing as we go along. Sounds like a plan!
The upside is that we now have a larger role in the overall project -- the rigid assembly line definition of requirement > designer > dev is losing it’s rigidity. The downside, if you can even call it that, is that as a designer you have to live with levels of uncertainty because you’re designing as the project progresses and sometimes there will be unknowns that will remain unknowns.
Theory’s great but let’s get practical here.
At Pathfinder, we do user driven software development which means the users’ needs and requirements define the features needed for the application. So much more accurate than throwing darts on a board or gazing into a crystal ball.
User research yields user modeling; user modeling, in turn, informs data modeling. But it’s of no use if the research is ignored by the developers. Integrating design into the entire SDLC meant creating meaningful documentation. I’ve had very good luck diagramming personas in a UML style, which is a language most developers are comfortable with.
And a tenet of Agile is user stories. I take the high-level needs of the personas and begin to diagram out the tasks. I also start to write the user stories for each tasks -- again, at a high level but at this point in the project, that’s all that is needed in order to get an idea of the overall scope of the project.
Our high-level user stories generate the Feature List. Now we can start scoping the project and determining what needs to be built and when it can be built -- iteration planning. Once that is accomplished, we start writing requirements, but only for the features slated for development in the upcoming iteration.
A feature, in our world, is something that can be developed in one iteration, regardless of how your team defines the length of an iteration. A feature page explains the design of that feature.
Each feature page has the above listed sections -- examples follow.
Our user stories state the user needs and the business benefit from meeting that need. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete, i.e., when all the defined scenarios are met. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
User workflows should diagram the end-to-end flow for the feature. Sometimes a workflow can only be drawn with other features in the flow. If that’s the case, those areas need to be denoted as not being in this feature, to be developed later, etc. Some sort of indication that it’s in the flow to be helpful but not to be developed at this time.
The wireframe shows the screen layout and the annotations note the various widget behaviors.
Functional specifications describe how a feature will work and are written entirely from the user’s perspective.
The last line is the most important benefit in my book. Instead of being shuttled off to the side or having only a brief involvement, designers are now an integral part of the team throughout the entire life of the project.
Once you get out of the silo, you realize you have much more room to play.