20

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

I'm not saying that I 100% understand what you need, but maybe your are looking for something similar to Personal Kanban. It provides/visualizes you and your manager your actual status can help you see your activities as a whole helps you find your limitations (WIP), in other words how much tasks you can do in parallel provides your manager the possibility ...


11

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


9

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

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

Agile Manifesto says that you should value Responding to Change over Following a Plan, however it doesn't mean that you should include every Change Request demanded by Client ASAP. Look at Scrum - you have Iterations and when you decide upon stories that would be acomplished during the Iteration the scope is frozen and you can prioritize tasks for the next ...


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

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


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

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

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


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

When you apply for the PMP, and it is time to document your 4500 hours (if you have a college degree) or 7500 hours (if you do not have a college degree) of leading or directing project tasks, you will be asked to indicate the number of hours in each of the domain areas (Initiating, Planning, Executing, Monitoring & Controlling, Closing). So, let's say ...


6

In general, release notes follow a format like the one below. You may or may not include all of these sections, depending on what is relevant to your product type and what your stakeholders deem necessary/useful for information dissemination both for them and for your customers. Product Name Version Number (Be consistent with major.minor.revision ...


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

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


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

So, what document/diagram is needed or better to have in a software project? In short, Those ones that helps you. You could write down all available documentation and generate all possible diagrams... and if you don't know how to use them / keep them updated, it will be a waste of time. I'd say that maybe the inner question would be what's the most ...


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