Scrum for scatterbrains
Scrum for scatterbrains
Preparation
Create a good user story description
The user story description should contain every info you need to finish the user story. Write down acceptance criteria.
Create meaningful tasks
Create tasks that are named well and describe what should be done in the task. If a task relies on another resource, put it first and try to get the requirements set up first in the sprint. Create tasks that cover the fulfilment of your user story (see Finishing a user story: Definition of done below).
Making progress
Tasks cannot be worked on because of missing resource.
Mark the user story as blocked. Write down what blocks you. Talk to who can help you. If you have to wait for someone for more than 5 minutes, work on another user story until you get an answer.
Task needs knowledge you don’t have.
Try to figure it out for a maximum of 15 minutes. Ask someone in your team for help if you exceed this 15 minutes. If needed, make an appointement.
Note things you want to show in the demo at the end of the sprint.
You implemented a well hidden feature or something that needs some knowledge to be understood? Write down how to explain what this feature/change does so you will be able to show it in the demo. Try the steps needed for demonstration before the sprint review.
Finishing a user story: Definition of done
Are all acceptance criteria fulfilled?
Try to use the application the way it’s intended. Does everything that is required by the acceptance criteria work?
Has the code been reviewed?
Code reviews are essential in software development. Let someone else look at and criticize your code. Some bugs can come up right now. You can improve your coding skills.
Is the source code checked in to version control?
Source code that isn’t in version control doesn’t exist for anyone else but you. If you didn’t commit your changes, your truck count equals 1 at all times!
Is your code released and in production?
Build a release of your code and put it in a state that can be accessed by the product owner. This can be checked by preparing yourself for the demo. Test the steps of the demo on the production environment or it’s equivalent. You might want to test your application on someone elses computer. (“Works on my machine” is bad!)
Did you comment the code and application well?
Documentation on how to use the application as well as what the code does is necessary for anyone else to use the application or continue development.
Did the product owner accept the US as done?
The product owner can always tell you if your changes fulfilled the user story. Should normally be covered through a thorough set of acceptance criteria.
Did you prepare the demo?
Show what your application can do in the sprint review. Be prepared for the demo and questions that your team might ask.