22

I think Retrospective is more appropriate name in this case Imho, project is dead when it has been aborted (or abandoned), if it has been successfully deployed then the project is very much alive (the code is there and it works!).


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

When anyone asks this question in this way, it implies the desire to measure for the sake of measuring, an end versus a means to an end. You metrics pop out as a result of decomposing your project goals. Any other measurement that has no parent goal will be looked at by bored stakeholders, who will eventually learn to ignore that report. Goals are ...


10

Every industry has lingo. It slowly evolves and becomes a sort of sub culture of the industry itself. Even if technically not correct in terms of a literal definition or even proper grammer, it becomes okay and common and accepted. So, no matter how any of us dissect the word, I doubt any of us can say we have never heard anyone use post mortem in our ...


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

Scrum Does Not Prescribe Development Practices Scrum is not a development methodology; it's a project management methodology. The Scrum process holds no specific answers for you from a requirements standpoint. Scrum Provides a Framework for Your Questions However, Scrum holds that the questions you are asking are part of the self-organizing that your team ...


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

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 ...


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

Post-mortem also has strong connotations in English of examining something dead to see what killed it and it is hard to see why it would be appropriate for a successful project. Lessons learned is better as it covers positive and negative experience from a project. Your gut instinct is correct and you can do your bit by not using the term in that sense and ...


7

I think is it completely fine. I googled it and organizations outside of the Agile world often call their lessons learned sessions postmortem. I found a great article by Jeff Atwood about postmortem in case you are interested. Pawel also has a post about the very same topic and he called it postmortem (in 2008). The naming is interesting though: I found ...


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

In my experience, we should distinguish post mortem meetings from regular retrospective meetings. But I do not agree with the other answers as I don't think it only applies to a failed project. In software development, teams usually have retrospective meetings throughout the project, typically after each iteration, sprint or whatever you call them. 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

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

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

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

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

Sorry for the late answer but I just discovered this forum and joined it. There are many ways to look at documentation so I have to make some question (and assumption) to limit the field of this discussion. The first question is: are we talking of end-user's documentation (HTML files, printed manuals, etc.) or developer's documentation (JavaDoc and the ...


5

Unfortunately, I cannot recommend you a fixed template of Word/Excel/PowerPoint or other template, but I hope, that this answer can help you by creating one. A Postmortem Analysis is composed by a meeting and a documentation. Their base idea is the same, to figure out why was the client lost or why did the project fail. The investigation has to be ...


5

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 ...


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 ...


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