Sprint release documentation

Hi Meriem,

I'll try to help, but if my answer doesn't make sense, you may need to give some more details about the problem you're trying to solve.

Functional documents aren't always used within Scrum. In fact, one line of the agile manifesto is "Working software over comprehensive documentation", which means that documentation is considered less valuable than having something that works.

Why do the Account Managers need the documentation? If it is indeed important, perhaps the people developing the product should maintain/update this documentation every time they produce a releasable increment.

In Scrum, we have a definition of "Done", which means an increment can only be considered "Done" if it meets the standards described in that definition. If it's important enough, the definition of "Done" should guarantee the documentation is up to date.

It is key to understand why the Account Managers need the documentation. Are they potentially handing this out to customers or is it for them to understand what new features are in the system?

If the documentation is potentially transferred to end users, I agree that the documentation should be worked on during development and it might be based on screenshots and explaining text. If it is just for the Account Managers to understand what is going on, they might be happy with what should be available from the backlogs used as User Stories. In that case the documentation could be as simple as: "This release implements the following User Stories", followed by the user stories relevant to the Account Managers.

hi, 

thank you all for your answers.

Why does the account managers needs a documentaion? -> simply, cause we have a customer oriented solution, and they need to know all about updated features which it will be presented to our customers.

they need to know all about updated features which it will be presented to our customers.

I wonder if the account managers have certain responsibilities which perhaps really ought to lie with the Product Owner.

In the past I have given guidance with release notes, but this is not a scrum master activity.

This is a PO role along with your account managers. This is a process area  you guys need to talk about to decide what you need in regard to documentation. 

Short example would be just high level over view you don't need to get into the technical weeds they won’t care anyway.

Very dumbed down Example might be something like this all made up.

New Features ( there might be some #id attached to each one)

1.Added functionality to application to generate reports for accounts receivable.

2. Users are now able to print invoices as PDF documents.

Enhancements

1. Users are able to open multiple accounts in multiple screens
2. Application is now useable in all web versions of all web browsers Chrome, IE, Firefox.
3. Customer can edit profile without calling customer support
4. Customer are now able to enter data in upper case or lower case in profile tab.

Bug Fixes

1. Users no longer get error “customer not found” when entering customer ID’s with a alpha character.

Just a example there are multiple formats just google release notes.

I'd like to hear from anyone working in a CI/CD environment with a manual process to keep up with Release Notes that are client viewable each week, or how you are adapting?

Prior to the CI/CD environment, the IT/R&D teams would rollout enhancements/bug fixes/new functionality every other month. A week prior to the rollout I would meet with the teams (I am not in either IT or R&D) to hear about the most noteworthy, then write up the client and employee-facing Release Notes and have them prepped for the day of the release. 

Now that we are in a CI/CD environment with rollouts twice a week we are at a loss for an efficient way to gather the completed "done" tickets with the most impact (UI and functionality) prepped and ready each week when the teams don't know sometimes until the day of a release which tickets are "done". 

We've already created a Board in XAP (Sprint/Ticket Tracker portal) to filter and target tickets, but that's about it. I'd love to hear how you solved this process either still manually or if you've automated it.

I appreciate any input!

we are at a loss for an efficient way to gather the completed "done" tickets with the most impact (UI and functionality) prepped and ready each week when the teams don't know sometimes until the day of a release which tickets are "done". 

If they lack release notes, are they Done at all?

Remember that in Scrum, the Developers comprise anyone whose work is needed to build a usable increment, including any necessary write-up. They should be privy to the same information about the state of development and be able to collaborate effectively on that basis.

You might also be able to get some of this information from the Product Owner since they are responsible for the communications with stakeholders.  But I agree with @Ian Mitchell that if release notes is an organizational requirement, the delivery of them should be included in the Definition of Done.