This seems to be related to http://kunagi.org/iss1131.html

For us the unusable Sprint History is a very painful aspect because being able to look up information from past sprints is essential.

Thank you for this feedback. In all my projects I never had the need to look into past sprints. So we think about canceling or changing this feature into a kind of archiving.

It would be helpful, if you could explain the usecases where past data is essential. Perhaps we can come up with better features to solve the unerlying problems...

I am happy to come up with some examples where looking at past sprints helped us in our daily business at my current customer.

1) As stories are and should not be modifiable during the sprint we use comments on the stories to document new learnings during the implementation on those stories. Those learnings stand in context with the story and might apply for future stories regarding similar features or products.

2) As there are freelancers involved in the project it helps during the payment process to look up on which things they were working to bill on the correct cost centers.

3) In general "learning from the past" especially with multiple teams involved that work with the same product helps to share the knowledge about the changes applied to the product.

My idea for an improved version of the sprint history would be a list of the sprints (maybe grouped by the releases) and clicking on a sprint would allow to see a sprint backlog like the one for the current sprint but for the selected sprint.

I agree with Stefan. We use this feature a lot, at least we try to.
Firefox keeps crashing while loading the history and in Chrome is more kind of a game of luck if it is displayed or not.

Currently it is really not usable anymore as the browser just stalls on medium sized projects. Can we work together on that and provide a solution?

Thanks
Stefan

On behalf of the congstar team, we would be happy to implement a solution.

This would be nice. I would recommend to target the following main tasks:

1. Prevent loading all sprint tasks at once, instead just the sprint entities (ScrumServiceImpl)
2. Change the history. For exampe a "load details" button which requests tasks for a single sprint
3. Handle navigation to entities from history (probably this will be the most difficult task)

One more thing: I am currently switching to GWT Super Dev Mode. The switch is not complete yet. Possible that you will have to branch the last release instead of HEAD.

If you have questions or need hints, please comment here. I will try to answear as soon as possible for me.

Hi Witek, I tried to set up my development environment to implement this feature but I am blocked by some incompatibilities with Java 7/8 and the latest version of Kunagi. Starting up the application brings up the following stacktrace:

[ERROR] Unexpected error while processing XML
java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
  at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
  at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
  at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
  at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
  at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
  at com.google.gwt.dev.util.xml.ReflectiveParser.createNewSaxParser(ReflectiveParser.java:65)
  at com.google.gwt.dev.util.xml.ReflectiveParser.access$000(ReflectiveParser.java:46)
  at com.google.gwt.dev.util.xml.ReflectiveParser$Impl.parse(ReflectiveParser.java:343)
  at com.google.gwt.dev.util.xml.ReflectiveParser$Impl.access$200(ReflectiveParser.java:68)
  at com.google.gwt.dev.util.xml.ReflectiveParser.parse(ReflectiveParser.java:418)
  at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:346)
  at com.google.gwt.dev.cfg.ModuleDefLoader.load(ModuleDefLoader.java:267)
  at com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:210)
  at com.google.gwt.dev.cfg.ModuleDefLoader.loadFromResources(ModuleDefLoader.java:170)
  at com.google.gwt.dev.codeserver.Recompiler.loadModule(Recompiler.java:214)
  at com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:105)
  at com.google.gwt.dev.codeserver.ModuleState.<init>(ModuleState.java:58)
  at com.google.gwt.dev.codeserver.CodeServer.makeModules(CodeServer.java:120)
  at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:95)
  at ilarkesto.webapp.GwtSuperDevMode.startCodeServer(GwtSuperDevMode.java:50)
  at scrum.server.ScrumWebApplication.startGwtSuperDevModeCodeServer(ScrumWebApplication.java:208)
  at scrum.server.ScrumWebApplication.ensureIntegrity(ScrumWebApplication.java:149)
  at ilarkesto.di.app.AApplication.start(AApplication.java:128)
  at ilarkesto.di.app.ApplicationStarter.startApplication(ApplicationStarter.java:57)
  at ilarkesto.di.app.WebApplicationStarter.startWebApplication(WebApplicationStarter.java:34)
  at scrum.server.ScrumWebApplication.get(ScrumWebApplication.java:409)
  at scrum.server.common.StartServlet.onPreInit(StartServlet.java:83)
  at ilarkesto.webapp.AServlet.init(AServlet.java:137)
  at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:534)
  at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:346)
  at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
  at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:786)
  at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
  at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
  at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
  at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
  at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:541)
  at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
  at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
  at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:162)
  at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
  at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
  at org.eclipse.jetty.server.Server.doStart(Server.java:282)
  at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
  at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:740)
  at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:522)
  at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1104)
  at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:844)
  at com.google.gwt.dev.DevMode.main(DevMode.java:322)
Sat Jul 05 19:07:55 CEST 2014 
    FATAL ApplicationStarter   Starting application failed. Application startup failed. Data integrity check or repair failed. <- com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) <- UnableToCompleteException: (see previous log entries)
java.lang.RuntimeException: Application startup failed. Data integrity check or repair failed.
    at ilarkesto.di.app.AApplication.start(AApplication.java:132)
    at ilarkesto.di.app.ApplicationStarter.startApplication(ApplicationStarter.java:57)
    at ilarkesto.di.app.WebApplicationStarter.startWebApplication(WebApplicationStarter.java:34)
    at scrum.server.ScrumWebApplication.get(ScrumWebApplication.java:409)
    at scrum.server.common.StartServlet.onPreInit(StartServlet.java:83)
    at ilarkesto.webapp.AServlet.init(AServlet.java:137)
    at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:534)
    at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:346)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:786)
    at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
    at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
    at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
    at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
    at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:541)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:162)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.Server.doStart(Server.java:282)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:740)
    at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:522)
    at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1104)
    at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:844)
    at com.google.gwt.dev.DevMode.main(DevMode.java:322)
Caused by: java.lang.RuntimeException: com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
    at ilarkesto.webapp.GwtSuperDevMode.startCodeServer(GwtSuperDevMode.java:54)
    at scrum.server.ScrumWebApplication.startGwtSuperDevModeCodeServer(ScrumWebApplication.java:208)
    at scrum.server.ScrumWebApplication.ensureIntegrity(ScrumWebApplication.java:149)
    at ilarkesto.di.app.AApplication.start(AApplication.java:128)
    at ilarkesto.di.app.ApplicationStarter.startApplication(ApplicationStarter.java:57)
    at ilarkesto.di.app.WebApplicationStarter.startWebApplication(WebApplicationStarter.java:34)
    at scrum.server.ScrumWebApplication.get(ScrumWebApplication.java:409)
    at scrum.server.common.StartServlet.onPreInit(StartServlet.java:83)
    at ilarkesto.webapp.AServlet.init(AServlet.java:137)
    at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:534)
    at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:346)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:786)
    at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
    at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
    at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
    at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
    at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:541)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:162)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.Server.doStart(Server.java:282)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:740)
    at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:522)
    at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1104)
    at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:844)
    at com.google.gwt.dev.DevMode.main(DevMode.java:322)
Caused by: com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
    at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:349)
    at com.google.gwt.dev.cfg.ModuleDefLoader.load(ModuleDefLoader.java:267)
    at com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:210)
    at com.google.gwt.dev.cfg.ModuleDefLoader.loadFromResources(ModuleDefLoader.java:170)
    at com.google.gwt.dev.codeserver.Recompiler.loadModule(Recompiler.java:214)
    at com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:105)
    at com.google.gwt.dev.codeserver.ModuleState.<init>(ModuleState.java:58)
    at com.google.gwt.dev.codeserver.CodeServer.makeModules(CodeServer.java:120)
    at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:95)
    at ilarkesto.webapp.GwtSuperDevMode.startCodeServer(GwtSuperDevMode.java:50)
    at scrum.server.ScrumWebApplication.startGwtSuperDevModeCodeServer(ScrumWebApplication.java:208)
    at scrum.server.ScrumWebApplication.ensureIntegrity(ScrumWebApplication.java:149)
    at ilarkesto.di.app.AApplication.start(AApplication.java:128)
    at ilarkesto.di.app.ApplicationStarter.startApplication(ApplicationStarter.java:57)
    at ilarkesto.di.app.WebApplicationStarter.startWebApplication(WebApplicationStarter.java:34)
    at scrum.server.ScrumWebApplication.get(ScrumWebApplication.java:409)
    at scrum.server.common.StartServlet.onPreInit(StartServlet.java:83)
    at ilarkesto.webapp.AServlet.init(AServlet.java:137)
    at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:534)
    at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:346)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:786)
    at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
    at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
    at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
    at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
    at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:541)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:162)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
    at org.eclipse.jetty.server.Server.doStart(Server.java:282)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
    at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:740)
    at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:522)
    at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1104)
    at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:844)
    at com.google.gwt.dev.DevMode.main(DevMode.java:322)

Any ideas what I can do to make this work?

Thank you in advance
Stefan

In the ilarkesto project there is a script update-libs.bsh which loads the required libraries. You also will have to use Java 7 at least.

The error comes from the GWT SuperDevMode Code Server. You will have to provide it with access to all Kunagi and ilarkesto sources. I have done this by adding them to the Tomcat launch configuration.

In the enterprise we often need to look at the history as part of a project retrospective for product marketing(either to defend ourselves against product owners with short memories or to provide history for a change in product owner). We also, need it so we can go back and confirm that an issue or story really was part of a release either to answers questions about what and when a feature was done or to help trouble shoot something in production.

I am really happy that this will be fixed as in real-life projects the sprint history becames that slow that every browser will collapse from the much never-ending javascripts!

Anyways, because my collegues complained about this, I made a workaround as a simple shell script that parse the xml files and generate the pdf download links for each project and each sprint! I have found out, that even though the sprint history takes and endless loop-feeling in our big project with over 20-30 sprints, the pdf export link works like a charm!

I tell you this, because you might work out the same thing as a temporal solution, or you can just put a table like that I made into kunagi itself:

<id> <project> <pdf_export_download_link> <label>
<id> <project> <pdf_export_download_link> <label>
<id> <project> <pdf_export_download_link> <label>
...

^^This is what I generate. I did it in bash as it was much faster than fixing your source code even though we are programming in java every day. Anyways... in bash it took 1-2 hours to process your internal xmls and produce a page with these links (I have found that the project hash identifier is in the link, so if you know the project and sprint ids then you have the link for pdf download - it is easy!

Is there any progress on this? I do not see this sto236 anywhere neither among "issues & bugs" or "development". Is this fixed in some version then?

I am happy with my workaround, but there are some people who are not because they are much less "techy". For them the solution is to use some other product like xyz or zxy (I do not want to name and advertise them). What I actually hate in those products is that they are not purely advocating scrum practices properly, but support old-fashioned and non-agile thinking too much (like "assigning" tasks to people instead of them taking the tasks). I am happy with the approach of kunagi that tries to make you think agile not only to use the canban board and some terminology. For people who want always the old ways, it is a weapon that the history loading is "not working". They do not care for my workaround and just label it hacking around things so they can feel they are right.

Is there a chance this is working in a new version?

This is implemented in the current version of Kunagi (although I have trouble pinpointing the exact release... presumably one around the end of 2013).

In fact, I am looking at your comment in our project's Sprint History right now, where the respective Sprint was loaded on demand to show me sto236. The rest of the Sprint History is static with the option to download the PDF report and a button to load the (in-program) Sprint details manually.

Dear artjom,

I will see with the latest version when I have time for it, but the problematic version says: "Kunagi 0.26" and it still have the problem. For me it sounds like a version that is much later than 2013, but I guess it is not the latest one either.

We have well over 32 sprints and when I open the sprint history I can see the first and the second. Also I can scroll down a bit if I am fast enough - but the whole screen gets frozen right after that and the scripts do a time-out. Maybe we have an other error that affects the sprint history but we already have the lazy version???

I do not know if the GUI have been changed or not in this sto236, but for me the gui also seems to be exactly the same as it is in the version we are using for the day-to-day business - just shared this to maybe help investigating.

The best solution would be a page where I can see only the list of sprints and they would be opened only when I click on them... That would work for sure I think.