Skip to main content

How do you manage product documentation in scrum

Last post 11:33 am December 10, 2014 by Ian Mitchell
9 replies
01:18 pm November 14, 2014

Hi. I'm trying to make better implementations of scrum and this is a doubt I have I have since a few years. And maybe the answer leads my to realize that I had a bad understaning of scrum.

Think on this scenario:

Jan/01/2014 - New project starts, user stories are identified and implemented.
March/31/2014 - Final sprint is done and the product is released to a happy client

Now, we're in november and client needs a whole refactor in a funcionality.
How do you handle this questions:
- If you have to assign this to a very new team,
- how do they understand the product?
- do they have to search for the whole bunch of done user stories?
- The team has to create new user stories to implement changes in funcionality?
- Any other thought thay may add value to this question?

02:45 am November 15, 2014

If release was deferred to the final sprint as you say, then Scrum was not well implemented. Value should be released incrementally and in accordance with a Definition of Done that is fit for purpose. A good DoD will address handover and training needs for the continuation of the Product as soon as it is known that the original Development Team will be stood down.

I suggest you have a release retrospective with the client to consider these matters before moving forward with any further development.

07:27 am November 17, 2014

Thanks Ian, I appreciate your answer. I think I can split this in two parts:

Part 1, my scenario is hypothetical, not a real situation

First of all, this is just an scenario, it is not a real example. I'm trying to expose a possible situation.

Second, what I meant with

March/31/2014 - Final sprint is done and the product is released to a happy client

is that the final release has been delivered, with several deliveries in between and value was added incrementally.

Third: DoD is supposed to be ok, because the client have been using the product.

So, when I said this:

Now, we're in november and client needs a whole refactor in a funcionality

I was thinking on a scenario like this: Imagine that in november, government changes a law and that has impact on the project functionality. how do you handle this?

Second part, my current reality

Now, going back to reality, I have a scrum project in course, and people is really new to scrum, and DoD is having problems. And yes, we're having retrospectives about how are we doing. however we need to move on, so:
How do you manage in scrum this problem?
Do you bring back old US and re-write them or just create new user stories?

Thanks again for your support

01:23 pm November 17, 2014

> Do you bring back old US and re-write them or just create new user stories? 

You don't bring forward old stories. They were placeholders for conversations that have already occurred and are now in the past. That means those stories are now finished and spent.

What you should bring forward are the acceptance criteria for those stories, preferably in the form of automated tests. Tests like this help to protect an existing product from unwarranted changes in the future. Where change is in fact warranted, you can then look *back* on the corresponding user stories for context, and write new ones that are a better fit for the new purpose.

06:50 am November 18, 2014

Thank you Ian. Let me see if my conclusions are correct:

- After the final release, all the product documentation is written under the user stories and the acceptance criteria
- Every thing you may need review in order to analyze how and why something is working in certain way, should be written in the user stories and the corresponding acceptance criteria for each one of them.
- Every user story is identified in the begining (early stages) and you go deep into it when you plan it for a specific sprint.
- Acceptance criteria should be identified and described for every user story usually when you make a sprint planning

03:35 pm December 3, 2014

Fpr me it just sounds like you do not have any automated tests which will validate the new extensions agains the old features.
I would recommend you first to make sure you have automated tests implemented before you go ahead with the project. this will guarantee you that the available features will still work.

10:28 am December 9, 2014

There is no chance to have automated test cases, it is a technical issue and it is not possible.

02:08 pm December 9, 2014

Really no chance at all ?
How can you hope to deliver shippable increment every sprint if all your tests are manual ?

10:37 am December 10, 2014

It is a technical issue, no way to automate.
And, as scrum is supposed to work on changing requirements environments, this should not be a problem, what do you think?

11:33 am December 10, 2014

In Scrum each increment must by definition include all previous increments. Acceptance criteria associated with requirements implemented in prior increments may therefore be impacted by future sprints. This implies that some form of regression testing will be necessary if the quality of each cumulative deliverable is to be asserted...and that is a tricky thing to scale manually.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.