Relevance & Ownership of project artifacts in Agile Scrum World

In my opinion the answers to your questions are no, no, no.

Why would those documents still be necessary if you are going to incrementally deliver value based upon the feedback you receive from stakeholders?   One of the reasons that the Agile Manifesto for Software Development was created was to combat the standards you are still trying to follow.  Plans are very seldom accomplished in fluid situations and if they are there is frequently a disconnect between what was produced and what is needed given the time that passes. 

You are still trying to define the totality of the work that is being requested before you know what it will take to do it.  And you are also saying that you know exactly what the end user will want/need at the end of the project.  In today's economies situations are changing daily and in some industries hourly.  Waterfall works for situations that are very clearly defined, extremely stable and non-volatile. Scrum/Agile works in situations that are fluid, under constantly changing conditions and complex in nature.  All of the documents you are referring to are artifacts of Waterfall. 

Given that the documents are not needed, the default answer to your second and third question has to be no. 

The Agile Manifesto for Software Development makes things pretty clear. 

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

I look forward to hearing what others say on this topic.  

Well, in any project, you need some kind of "Product Vision". Maybe it is your "Project charter" ?

If it is, of course it is the business of the Product Owner.

About risks, Scrum is a risk management framework. The risks are adressed through the Product Backlog => business of the Product Owner.

About cost, again, the Product Owner has datas about cost of each and every Sprint and the PO should assess the value of each increment.

If some documentation are required because the Product need it (and not because the process need it), for instance for regulatory concern, it can be part of the DOD or it can be specific Product Backlog Items.

Working software OVER comprehensive documentation

=> limit waste, use your time to create "value", mainly in the product itself, possibly in some valuable documentation

While I agree with Daniel's and Olivier's positions, I'd say it all depends on the context. I'd argue that, even in the purest Scrum environment (or the perfect setup, Agile or not, - which, by the way, can't mathematically exist :) ) there would still be a need to have some documents - not too many, not too few, but just enough. The question is, how much is "just enough" documents?

I'm all in favour of having documents within the Scrum team, and outside (organizational ones). In fact, I am (and have been) using documents which I either create or update, in order to bring (or improve) transparency, ensure actions (post retrospectives, or my own, or for colleagues in other teams) are visible, understood, and followed up, and so on. But I always strive to keep it at the bare minimum (measure twice, cut once). Just enough. With some organizations/teams, I succeed; with others, I fail. And when I fail, I try to learn as much as possible and avoid making the same mistakes.

So I'd say "Project Charter, High Level Project Plan, Stakeholders’ Management Plan, Financial Planning & Budgeting, Risk Mitigation" MAY still be "relevant & necessary", depending on the characteristics: company, ithe industry(ies) it covers, country/continent, status (traditional-operating, in "Agile transformation", Lean maturity, etc), internal politics, and so forth.

• These documentations are still relevant & necessary ?
• If yes, someone has to be held responsible for such documentation ( Scrum Master / Development Team Member / PO ) ?
• The documentation effort will be a part of the user story ?

Why would you use these documents, for whom and how will they be used?

Who is accountable for creating the BI's in the team?

If the documentation were not to be added in the user story, what will the impact on the customer be if the user story is released? 

Dear All,

Thanks a lot for your valuable insights, highly appreciated. A few quick continued threads.

• @ Mr. Sander, generally, in the current situation, the business sponsor of the project needs the commercials. And the project is one of the children projects in a program where the program manager wishes to know in case if any risk / issues pops up from a project, which in turn, might affect program level risk

• @ Mr Olivier, I was also thinking along the same line, however wasn't sure of it. Thanks a lot for clarifying.

• @ Mr Daniel, thanks for sharing your opinion. I was just asking myself, say in a project ( Agile Scrum ), a budget allocation is made towards the beginning of the year. Now, on a regular basis, someone has to verify whether there is any budget overrun / budget under run / budget actuals > budget accruals or budget actuals < budget accruals etc etc. So is it that these are to totally handled by someone else and should not be a look out of the scrum team ?

• @ Mr Eugene, was your experience as a Product Owner / Scrum Master ?

I really like the posts after mine.  I have been reconsidering my position on all of this.  There have been very valid arguments for the existence of the documents posed.  I also will admit that most "scaling" methodologies will include these elements and for good reasons.  But I haven't been actively involved in any situation where scaling was necessary and thus the documentation discussed were overkill and unnecessary.  In fact, when they were created the usefulness of them was so much less than the effort to create them that the organizations usually abandoned or majorly adapted them. 

But after these arguments, I can see how variations of the documents could be useful especially in some heavily regulated, pure consultancy companies.  But I still feel that the "old" style documents are totally wrong for a Scrum, or any real Agile, organization.  Variants based on the empirical, iterative models should be invented and used. 

Watching for more conversation.  Thanks all for the insights.

About documentation, I usually ask a few open questions like :

Written when and by who ?

To be used/read when and by who ?

For what purpose ?

we are used to see few documentations like Project Charter, High Level Project Plan, Stakeholders’ Management Plan, Financial Planning & Budgeting, Risk Mitigation etc. etc. Now in an Agile Scrum world, am I correct that

• These documentations are still relevant & necessary ?
• If yes, someone has to be held responsible for such documentation ( Scrum Master / Development Team Member / PO ) ?
• The documentation effort will be a part of the user story ?

When work is understood to be emergent, is this documentation more likely to be an asset or a liability?

I would like to revive this thread!

As a consultant in the software dev industry for 30+ years, I have seen the highly counterintuitive role that documentation plays in software development and the inarguable value it delivers to both creators and users.

At the same time, I have rarely met a software engineer in my career who believed that documentation was anything other than a tedious, painful, loathsome necessity.

As a result, I am not remotely surprised by universal approval among engineers for any methodology that purports to dispose of the need for it.

In my experience, this is just a pernicious form of self-serving thinking which ignores the realities of both software development and the objective of delivering products which really work for users.

Thoughts?