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


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

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


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

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

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

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

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

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

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

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

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


4

The RASCI being developed is intended to highlight the support model going forward. From my perspective a RASCI encompasses all aspects of the project including handover. It can do both, or neither. RASCI is just a tool to get agreement and understanding on who is responsible for what and at what level. If it's useful to have as part of your project (lots ...


4

One of the four values of agile is "Customer Collaboration over Contract Negotiation." The first thing to ask is "what is best for the customer?". Once you've done that, then you ask "is it covered by the contract?" and only then do you delve into the "do we ask for more $". Specifically focusing on your issue the first question I'd ask is who was ...


4

this is the job of the engineer working on the issue as they're the one most familiar with it. Technically, no. The engineer working on the issue is the one most familiar with the technical details of said issue. The one most familiar with the issue itself would be a Business Analyst (BA). Furthermore, engineers often have different priorities. I would not ...


4

Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as a tracking and reporting tool to interface with the core (enterprise) Agile development team. The focus ...


3

TL;DR Your assumption that you need to track changes across multiple revisions is limiting your scope of change control options. So is your use of the Microsoft Word format. I'd reconsider both unless you can: ensure you have a single document owner, and track textual changes independently of your change-control approval process. However, if you can't ...


3

Welcome to StackExchange- Project Management. This is not an uncommon issue in large enterprises. Clear ownership of deliverables can be a challenge. Given you're new, you probably are in a good position to do something about it, if you tread carefully. I would recommend a two phase approach. Step 1- Conduct Stakeholder Interviews: I have used this ...


3

The communication gap I often see between a technical person and a non technical person is getting from technical component to the end business result. When requirements are being developed and identified, it starts with what you want to happen for the business, which is decomposed to a functional requirement, which is decomposed to a technical requirement, ...


3

Tracking Specifications and Strategic/Architectural Decisions I want to know why we made the decision to implement a module in a way and why we changed it afterwards. This can be driven at several levels. I will address the project management and engineering levels, but for a deeper dive into how to track these things as an engineering process you should ...


3

Many of the design or project management decisions are the result of "trade-off analyses", and trade-offs are a method for validating requirements and/or designs. A sound Systems Engineering approach to projects would yield these Validation artifacts daily, as time progresses. Without having to remember what the reason was. Configuration Control processes ...


3

Are the goals that the review can be audited? or to prove the auditor is doing his/her job? We document them as new tasks/discoveries on our Scrum-board and some just picks them up. I think the main goal of code reviews is knowledge sharing and finding recurring code mistakes, not the documentation, unless you need it by law :) Checklist based code reviews: ...


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