Sprint 1 Retrospective

-
So last night I started thinking about sprint 1 and how it went, what I'd do differently etc. for the sprint retrospective. The biggest thing I learned is that there's no way I can put in as much time each week as I'd like to on the project. I would love to put in 20 hours per week but that's just not going to be possible while maintaining my sanity. The biggest problem is that weeknights quickly get crowded, so I can really only get in a half-hour here or an hour there M-F. As such I need to concentrate on getting a lot done on the weekends. I'm going to start designating one day per weekend as a project day and do no other activities on that day. This should help a lot, I hope.

 The main thing I will be sure to do differently is to set up the demo much earlier. I waited until Sunday night and then ran out of time. Next time I'll set it up in the morning/early afternoon of my designated project day in case something goes wrong. I'll officially end my sprint before I set up the demo (Friday or Saturday night I suppose). I can do a retrospective and planning meeting without meeting with my professor, I think, since really I'm pretty much determining what to do right now. So I'll do those on the  night of the project day, and if I get any actual work done after that it will count as part of the next sprint.

 The actual work went ok, it was simply a matter of time. And my estimations weren't as horrible as I thought they'd be. I finished the tickets "Restrict access to the HSQLDB to the server on which it is running" in 2 hours and "Change the way passwords are stored and transmitted so that they are encrypted" in 6 hours. Much of the time for both tickets consisted of research. I started on "Add logging and propagate exceptions instead of swallowing them" but was unable to finish completely; in retrospect I should've split this into "Set up logging" and "Insert logging code where necessary". Setting up logging is complete, so I'll create a new ticket for inserting logging code and do that for the next sprint. I will also be attempting a smaller, hopefully more realistic, amount of ideal man hours for the next sprint.

 The final issue I had is that I didn't do well at all on keeping track of the the work left for the burndown chart. Basically I kept forgetting. So I'll make sure to actually track that for the next sprint.

 So the summary is I'll try and get a better schedule set up for working on the project, be more realistic about how much I can work on it, keep track of the work left on tickets and update the burndown chart every day, and procrastinate less when setting up the demo. 

Just for grins, here's my burndown chart, though it's pretty badly inaccurate and contains a lot of guesswork:
 

Comments

Post a Comment

Popular posts from this blog

"Does it get easier?" Yes, but Also No...

-
Image
Image by Arek Socha from Pixabay It's complicated... "Does it get easier?" I see some form of this question asked a lot in beginner programming groups. I always struggle with how to answer this honestly and clearly, because the truth is not that simple. In some ways it does get easier, but in other ways it is almost always going to be difficult if you are advancing in your career . If you are a programmer and your job is easy for years on end, the most likely explanation is that you're in the kind of dead-end position that people try to avoid, not the kind of position people dream about when they think of becoming a developer. Most likely you are not getting better at being a dev, not working with new tech or solving new kinds of problems, not being given more responsibility, etc. etc. etc. I've seen some pushback from other newbie programmers on the idea that it could remain difficult past the initial learning stage. Notably I have never once seen somebody who...
Read more

How to Land Your First Dev Job: Develop Yourself, Market Yourself

-
Image
Image by magnetme from Pixabay In the coding and tech groups I'm in, I see the same question asked over and over by folks who are just learning to code, finishing up a bootcamp, degree, or other training program, or who have been looking for that first job for awhile and not having any luck: "what do I need to do to get my first dev job?" There's a whole ton of info out there on this topic, but it's scattered all over, so I thought I would gather together the best resources I've come across and share them, along with a bit of context, to try and help everybody struggling with or just plain wondering about this. There are a lot  of things you can do to improve your chances of finding a job and hopefully shorten your job search. They are broadly divided into 2 categories: developing yourself and your skills, and marketing yourself and your skills. Note that you don't need to do everything on this list, nor do you need to do it all at once. This is an "...
Read more

Git. The WHAT and WHY Edition.

-
Image
Lately I've seen a lot of new/aspiring developers talk about difficulties learning git . I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git. First, I want to make it clear that if you want to be a programmer, any kind of programmer, you need to know git. You just DO. This is the short version of the answer to "why should I learn it?".  The medium length a...
Read more