13

In the manifesto for Agile software development one can read: Working software over comprehensive documentation This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code. That being said, user stories and acceptance criteria might be all you need to understand the requirements, ...


10

In either case the big issue is with the data contained becoming stale. A wiki will have more robust version control information. We collaborate using markdown and gists on github to build out documentation of component parts where members are responsible for portions then the whole document is compiled and reviewed for completeness. In terms of using ...


9

TL;DR Your problem is not actually with granularity or "task bloat." Your core issues appear related to exceeding the team's work-in-progress capacity, and allowing the team to ignore the agreed-upon definition of done. Integrating Documentation with Tasks Network engineering is not like programming. While collecting router configurations could ...


9

Your first course of action should be to secure some legal counsel and get their opinion. Asking a message board for legal advice is only marginally better than doing the same for medical advice... at least in your case you only stand to lose money. That being said, unfortunately this kind of thing is not uncommon. Customers change their minds all the time, ...


9

You've identified a risk, and a possible solution. I'd refrain from considering your solution (more documentation) as "the" solution and ask them to apply it straight away. You're working with a team of experts, which will likely have a different point of view on the matter, so do not expect to be able to "motivate" them into doing what you want... engage ...


9

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change ...


8

An aspect of the work experience documentation that is often confusing for people has to do with overlapping projects. Here’s the simplest way I’ve found to explain it: PMI is looking for two things regarding work experience on the application: a number of unique months and a total number of hours of leading and directing. Earlier posts handled the leading ...


8

A couple of suggestions: Code Quality Tools It is worth thinking about using automated code quality tools like Findbugs, PMD and Checkstyle. Ideally get the team to agree on a set of coding standards and implement them as templates in the various code quality tools. Then run the tools from continuous integration and possibly even fail builds when the ...


8

Here's my TL:DR answer: No! The engineer shouldn't be working on something if the business value isn't already defined. It's the voice of the customer (product manager, product owner, business analyst) that should be defining the business value. Said business value should be agreed to by the business before asking engineering to size the work for ...


7

@Mamoo is right. A new and junior project manager does not have the authority or influence to jump to a solution and ask the team to implement it. Even as a two decade project manager I wouldn't try to impose a solution on the team. As PM you have to help them to find their own solution. To do this you first need to get them to identify the problem. Until ...


7

You've basically hit on the purpose of user stories. You see, user stories arose when we had large requirements documents that had all of the details the dev team could possibly need to develop the software. The problem with this is that those details take a long time to document and it turns out, they often aren't what the user wants (or at least miss the ...


6

That's a very perceptive question. The first document you should develop is your Project Initiation Document (or project charter as it is more commonly known). BUT the value of the project charter is not the document, it is the process of creating the document. The point is not to spread ink on dead trees, but to identify the key stakeholders in the ...


6

I am not a huge fan of automation without some level of human intervention. It is too likely that the business rules in your automation logic will be imperfect and will fail to catch what a human could catch intuitively. It is too likely that your team will get "dumbed down" if there is an overreliance on automated processes, in the same way that reliance ...


6

Great question, and I believe in keeping this as simple as possible without adding too many "rules" to what constitutes a task. A PO creates a requirement that needs to be done, this requirement requires work to be done in order to the job done. This work comes in the form of grooming analysis, coding, testing, documenting, deployment packaging, UI design ...


6

Having everything public on a Wiki may make people more likely to refer to it. In my opinion documentation I can't easily access isn't good documentation. I've advocated for and used Wikis on a couple of projects. There are systems, such as Trac, that combine a Wiki with a bug tracking system and links to the version control system. I've worked on a ...


6

Well the answer is really "It depends" mixed with "Why do they need it?" and "What's the least you can get away with?" This is really about interviewing your stakeholders and doing a 5 Why's type analysis. Find out why they need something, so you can then work to meet that need with the minimum work on your part or even not at all because it doesn't apply. ...


6

There can be no general answer to this. Multinational or public companies do vary greatly. Software developed by such companies varies even more in size, type, purpose, usage, life expectancy etc. In general, the bigger, longer used and maintained, more complex the software is, and the more people are involved (at the same time and/or over the long term), ...


6

Context Matters Acronyms and initalisms are useful shorthand when discussing a problem domain with others who share the same lexicon. However, such shorthand is highly contextual. For example, an "R.A." might mean Risk Analysis in an information security context, but a Residential Assistant in a college dormitory. Inspect-and-Adapt Your Communications Plan ...


6

Many agile projects don't produce a software requirements specification in the sense of a document that lists a bunch of "shall" statements along with some assumptions and dependencies, like what is described in ISO/IEC/IEEE 29148 or DI-IPSC-81433A. That doesn't mean such a document can't be produced, though. Often, agile projects will capture 'requirements'...


6

Documentation is always the stepchild of development. Although you could simply order them to do it, there are a few points to take care of when you want to motivate them: Demonstrate the problem Have they ever seen the problem? Right now it's an abstract problem. You think something might happen in the future. You will have better chances if you can provide ...


6

Input Artifacts for Behavior-Driven Development (BDD) For successful behavior-driven development, you need (mostly) the same documents you'd need for any other agile project, with the addition of executable tests for the business use cases. Some examples include: User stories or project backlog items that meet INVEST criteria: Independent, Negotiable, ...


5

The best reason for not using a Wiki is if you have key stakeholders who are uncomfortable or unfamiliar with them. If this is the case you may be able to go with a hybrid approach, i.e. msot of your documentation is on the Wiki while particular key documents (e.g. your baselined schedule) are static. For example, maybe you have a project business sponsor/...


5

TL;DR In our current project we have pushed documenting it (other than deep technical detail) out to the end of our sprints. Is this a sensible plan? Nope. Technical Writing for Agile Teams The Agile Maifesto values: Working software over comprehensive documentation...[T]here is value in the items on the right, [but] we value the items on the left ...


5

A common issue. There are a few approaches, but this is the one I use: Each change, or set of changes is captured in a new Change Request document. The CR document must capture the new requirements in as much detail as is required to a) approve them b) perform the functional requirements analysis c) do a reasonable estimate of the effort required to deploy ...


5

There are three agile principles that are at play: "Working software over comprehensive documentation" from the Agile Manifesto. "Simplicity--the art of maximizing the amount of work not done--is essential." This is one of the Principles behind the Agile Manifesto. The Single Source of Information from Agile Modeling, which brings together various ...


5

Leadership 101: Do not force the team to do something for the sake of doing something. On the surface, it seems to be a very nice idea, being poorly implemented. The straight answer for the question is no - it does NOT make sense to force engineers (coding-oriented people, who usually have collosal knowledge on programming but low communication skills) to ...


5

TL;DR The short answer is that you don't. Big, upfront planning is orthogonal to agile development. Instead, you should focus on iterative and incremental development with tight feedback loops to ensure that you're building the right things and embracing change throughout the project's life cycle. Big, Upfront Requirements an Anti-Pattern Doing detailed ...


4

Difficult problem, and I doubt there will be any simple answers. I would suggest a corrollary's to CodeGnome's law. First, decide what the process is - how do you make sure that a change is applied in all the appropriate places. Once you have that, figure out how to automate it. Automation is a tool not a solution. In your shoes, I'd apply change ...


4

Sounds to me like there are three clusters of opportunity. Document templates - How to write a document that supports others using the document. Document search/storage - How to store a document in a way that supports others finding the information rather than re-creating it. Documentation procedures - What do we record? I'd suggest that #3 is not where ...


4

First off, congratulations on taking the high road. Too many IT "professionals" that I've worked with would use this kind of situation to extort ludicrous salaries from their employers. We currently use the Confluence wiki, so that seems like a good place for the documentation to live, but the body of knowledge is both wide and deep, so I'm looking for ...


Only top voted, non community-wiki answers of a minimum length are eligible