3

If a project tree has branches such as Development, Business Analyses and Architecture pages, where should Functional specifications and Technical Specifications go? (i.e. Technical under Development, Functional under Business)

Is there a standard somewhere?

4

I'll make an assumption here, but it seems to me that you are thinking about your Agile project from a traditional project management perspective, where you focus on layers of work or on work packages that you need to prepare, plan, and then build, with each piece having to be accounted for in the correct place. You are focusing on project work basically. With Agile there is a different mindset, one that places greater importance on the product being built and on delivering value.

If that requires business analyses, architecture pages, functional and technical specifications, etc, then so be it. If not, then not. If some, then some. In other words, each Agile team within its context and domain, decides how to manage things, including documentation or specifications, but truly Agile teams will tend not to have such separations between the different parts of what they are building. As another answer mentions this can cause a separation and introduce obstacles to communication and collaboration while people are busy updating "their documents" and throwing them above the fence to someone else, back and forth.

In Agile, you choose an incremental and iterative approach and build small features that need to contain all things needed for people to understand what they need to build. And these things tend to stick together with the feature instead of being expressed as sections of different larger specification documents. In Agile you build products from items in a product backlog, not from specifications (at least not heavyweight upfront written specifications as traditional project management is accustomed to).

So if you are looking for a standard project structure, then at best that will be a properly refined and maintained product backlog and people work from the top of that. Otherwise, there isn't a standard one. Agile teams are self-organizing and self-managing and decide for themselves how to structure things in order to reach their goals.

2

The agile approach puts the emphasis on cross-functional teams, often consisting of business, technology and everyone else working together on some common endeavour. Think about what you really want to achieve by categorising artefacts as either development or business. Many people will prefer not to split things up in that way in case such a separation becomes an obstacle to communication and collaboration.

The team(s) should be able to decide what documentation is appropriate for their way of working. So much depends on the team and the kind of work being undertaken. It's very difficult to come up with a useful rule that fits all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.