Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: Post-Sprint Analysis and Reports  (Read 14302 times)
Technomage
Admin
Community member

Posts: 80



View Profile
« on: March 04, 2011, 11:58:14 PM »

The sprint officially ends on Tuesday, 10:00pm UTC at the start of the post-sprint report meeting. Everyone involved in the sprint should take some time between now and then to jot down their thoughts about the sprint as a whole. We'll use this discussion as a starting point for the post-sprint meeting on Tuesday.

The following questions should serve as general guidelines:
1. What worked really well in the sprint? What didn't go so well during the sprint?
2. What, in general, blocked your progress most often? What facilitated your progress most often?
3. What would your change about the sprint? What would you keep the same?
4. What is your overall impression of the sprint? Was it successful? Why or why not?

When posting, please start with a brief description of what you worked on during the sprint to serve as a bit of context.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

aspidites
Community member

Posts: 29


View Profile Email
« Reply #1 on: March 07, 2011, 11:38:08 AM »

1. In general, I thought the sprint went really well. Having specific areas of interest and a generous time frame in which to accomplish it seems to have worked out better than the generalized goal and liberty that previously drove the team. I especially liked the meetings. Not only was it helpful to know how everyone was progressing, it felt good to know that there was a specific time and place where I could voice my concerns about progress in general, hurdles I was facing, or to outright brag about what I finished! The biggest pane during the sprint was getting acclimated to the new work flow and submitting changes.

2. Two things blocked my progress more than anything else: Windows and SVN. As far as windows is concerned, I found myself having to cater to the platform to get things done, especially in the packaging department. Furthermore, not having a native Windows machine made it tough to test my work. As for SVN, I find myself making local branches quite often, which SVN doesn't support. As a compromise, I've had to adapt to git-svn, which generally gets the job done. However, problems arise when you try to submit changes, due to SVN's flat nature. I think I've finally got it under control, but using purely git would have helped in this respect.

3. I'd like a slightly shorter sprint with less tasks. I say shorter because there were a lot of devs on the team that finished quite early with nothing to do. I say less tasks (for now) because the current state of the code base makes it impossible to foresee some of the pitfalls that await us. In my case, It took a few days longer to merge the new settings module into the code base because I kept running into what (for lack of better phrasing) amounted to poor design decisions early on. The shorter list of tasks would allow us to adjust fire more rapidly.

4. Overall, I think it was a success. To an average user looking in it might not seem so because the only things that were added visually were the new character screen and the notebook gui. However, if you look at the number of commits to the source, the fact that there is now a (in my honest opinion) simple packaging system), the number of new members we've attracted (myself included), and roadmap
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #2 on: March 07, 2011, 03:51:53 PM »

Some developers having a slack is probably me Cheesy
Well, it was little for me to do. All agreed on using notebook as a main axis of all other UI items, which I'm so-so with, as it will be simply boring. It looks like qubodup made even the main menu on notebook, that used to be on a piece of rusty shim.

I have two conclusions.

First is the meetings did a great job for organizing work. I mean I was able to plan my effort better and do the things in the moment I feel was the right one to do a thing - not to early and not to late, so that there was not many issues to fix afterwards.

Second is, we should IMHO really take a closer look, each one of us individually, and have clearly set and valued long term goals (or epic user stories, if you like), like: content creation toolchain, playable game with basic features and so on. For example we were making character customization screen, which we could live without for a longer while, when Technomage left inventory screen, which is a must, on backburner, and we need content creation tools IMHO way more than actually customizing PC just to wander around in pretty much empty game. I know that code and mechanics that go with PC are important (like attributes and advancements under it are are necessary), just not the aspect of pre-game PC customization aspect.

As for the sprinting itself - the only other major issue that I can say is my GF calls you all "Fennecs", partially cause she like those animals, partially because we chat together happily, but mainly, I think, due to fennecs being cute night-time predators.
Logged

rowanthepreacher
Community member

Posts: 139



View Profile Email
« Reply #3 on: March 08, 2011, 01:41:54 PM »

Heh. Fennecs.

I didn't really do anything, but I have thoughts about the sprint.

1. We started working without knowing all of the dependencies. Everything hinged on everything else, and as a result there was much confusion. Once there was a clear task, however, things got done pretty quickly.

2. N/A

3. We should pick sprint goals with fewer priorities in future.

4. No idea.
Logged

Testiculos habet et bene pendentes.
kb1pkl
Community member

Posts: 24


View Profile Email
« Reply #4 on: March 09, 2011, 05:10:03 AM »

1. What worked really well in the sprint? What didn't go so well during the sprint?

It looked like there was a smallish bottleneck between departments, but it was mostly worked out. Maybe having department specific sprints would work out better in the future?

4. What is your overall impression of the sprint? Was it successful? Why or why not?

[placeholder]

As well, there were two things that blocked me. One was simply getting my system back up to a usable state. The other was having things to do. All the sprint tasks were covered by other people, so I just sat in the corner and played with toy blocks for a while. Part of that was my own bad.

(Sorry I couldn't make the meeting. Rehearsal ran abnormally long tonight)
Logged
qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #5 on: March 09, 2011, 04:22:54 PM »

I agree with the feeling that it got weird at the end and I think it might be related with nobody creating specific trac tickets.

The first two weeks were very staisfying and I felt like I had a lead because there were targets

After then it was just the epic user story of having a char creation gui for me.

I think we could have needed somebody to either define more specific tasks or somebody to push us (department people) to create more specific tasks.
Logged
qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #6 on: April 07, 2011, 02:07:32 PM »

I am going to make a blog post mirroring the opinion of the developers (coders,artists,designers) invovled. Would anyone like to add their opinion? Technomage? Smiley
Logged
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #7 on: April 09, 2011, 04:26:51 AM »

Yes, thanks for the prod qubodup Smiley

What went well? Cheesy
In general, I think the Trac ticket backlog was quite successful at keeping us organized and on-track. In particular, I thought that the Trac ticket dependencies (blocking, blocked by fields) and depgraphs (e.g. http://parpg-trac.cvsdude.com/parpg/depgraph/264) were very helpful for figuring out which tasks to prioritize. AFAICT everyone on the team seemed comfortable working with the Trac tickets and the backlog, though there was some hesitation in the beginning for those who hadn't dealt with Trac much in the past.

I thought that the twice-weekly sprint meetings were extremely useful at keeping everyone in the loop. Twice a week seemed like a good frequency to me - it gave us enough time to work on smaller tasks and report our progress, and also allowed us to quickly discuss and assign new tasks as needed. The strict meeting structure was good at keeping us on-topic, and overall I thought the meetings were very productive.

What didn't go well?  Cry
The momentum from the first two weeks died off rather rapidly in the second two weeks. Based my own experience and observations of the rest of the team, I think what caused this slowdown was a series of structural problems with PARPG which blocked progress in several departments. For instance, in the programming department I was not able to fully implement character statistics because the current model system makes it very difficult to add new things to characters and other game entities. In the graphics/GUI department qubodup and Q_x were unable to work with PyChan and its complexities and eventually I ended up having to work on both the PyChan GUI and game model code, neither of which were easy to deal with.

My only complaint about the meetings was that I would have liked some time to discuss solutions to problems we brought up during the meeting. In theory we were supposed to discuss solutions in-between meetings, but timezone differences and time commitments outside of PARPG made this almost impossible.

In the final week and a half of the sprint we lost barra and shortly thereafter myself due to family and school commitments, which I think contributed to the slowdown and made resolution of the sprint difficult.

What would I change?
I would like more time during the sprint meetings to discuss solutions to problems encountered during the sprint. Perhaps adding 20-30 minutes to the sprint meeting times? We could break away into smaller groups during this problem-solving meeting time, and those who don't have anything to contribute would be free to leave.

What is my overall impression of the sprint?
A fantastic success, though not for the reasons we originally based the sprint on. We did not fully implement any of the user epic stories and from a purely numerical standpoint only completed 68% of the tasks we set for ourselves. However, we learned A LOT about how to communicate with each other and how how to organize and deal with a series of tasks as a team. Before the sprint we were a bunch of individuals working in parallel, but during the sprint we came together to solve problems as a team. We now have an organizational framework that we know works, and I would say that is a major accomplishment.

We also discovered several major structural problems with PARPG which we may not have encountered working alone. It is extremely important that we deal with these structural issues early in PARPG's development, otherwise we may end up with product that not only requires an enormous amount of maintenance but that only a few key developers know how to maintain! Not a good outcome for an open-source project which relies on volunteers with a high turnover rate.

Conclusion
The sprint may not have gone as we originally planned, but I think we did a great job and learned a lot in the process. Now that we know what's blocking our progress we should regroup and start brainstorming about how to tackle those issues. Hopefully we'll be able to start another sprint soon and with the lessons learned from this sprint be able to make some real progress!
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #8 on: April 11, 2011, 06:12:29 PM »

I was a little bit concerned with the idea of single department sprints. I agree there are some tasks that are department-specific, (or exclude a specific department from work), but I don't quite understand how such sprints could work. There will be tasks requiring cooperation of many depts, so how to tackle those?

Instead, I'd propose rather careful investigation of every ticket we decide to work upon, in the way that we first vote, later check out carefully if chosen user stories are not blocked by some strange issues, (like this need for refactoring that occurred) and finally proceed with it or change it to another story and leave for further investigation, or tackle blocking issue instead.
Logged

Pages: [1]
Print
Jump to: