Sprint 1: Improve Security and Reliability
The first sprint, which I will hopefully start tomorrow, has a goal of improving the application's overall security and reliability. Right now I have some pretty egregious security violations, such as plain-text passwords, and most errors get swallowed, so it's very difficult to tell what the problem is when something has gone wrong. So I need to start remedying that.
The sprint backlog items I have selected are:
The sprint will be 2 weeks long. My story points are sorta kinda "ideal man hours" but really are more relative to each other than reflective of actual man hours. This is how we estimate at work so I'm used to it, and I'm generally more used to thinking in chunks of hours than days, so I'm going with it for this project, too. I'm being probably excessively optimistic in hoping that I can get 38 story points done in this sprint.
Note that my user stories don't conform to the normal rules of scrum because I'm filling all the roles, and the main goal of the project isn't simply to have a working piece of software but also to have proper processes, conform to best practices, learn more about software engineering, etc. So for this a user story that provides value or functionality can include just changing things so that they're being done the right way. For a commercial project obviously the stories would look differently.
The sprint backlog items I have selected are:
Priority | Description | Points |
---|---|---|
300 | Add error checking, unit testing, and integration testing using JUnit, DBUnit, FindBugs, etc. | 16 |
290 | Add logging and propagate exceptions instead of swallowing them. | 8 |
280 | Restrict access to the HSQLDB to the server on which it is running. | 2 |
270 | Add additional sanitization of input and other security measures | 8 |
260 | Change the way passwords are stored and transmitted so that they are encrypted | 4 |
The sprint will be 2 weeks long. My story points are sorta kinda "ideal man hours" but really are more relative to each other than reflective of actual man hours. This is how we estimate at work so I'm used to it, and I'm generally more used to thinking in chunks of hours than days, so I'm going with it for this project, too. I'm being probably excessively optimistic in hoping that I can get 38 story points done in this sprint.
Note that my user stories don't conform to the normal rules of scrum because I'm filling all the roles, and the main goal of the project isn't simply to have a working piece of software but also to have proper processes, conform to best practices, learn more about software engineering, etc. So for this a user story that provides value or functionality can include just changing things so that they're being done the right way. For a commercial project obviously the stories would look differently.
Comments
Post a Comment