It's always a good idea to take one step back in our busy days, and go back to the basics.
This is where it starts...... http://agilemanifesto.org/
Thursday, December 29, 2011
Monday, November 28, 2011
Eleven Equations True Computer Science Geeks Should (at Least Pretend to) Know
Eleven Equations True Computer Science Geeks Should (at Least Pretend to) Know
Interesting :-)
Friday, September 23, 2011
I have 6 departments, each with applications to maintain, and 4 developers. How do handle this in scrum?
You already know the root of the problem. Work your way from there...
1- Get the products owners (PO)/business...and let them know the situation.
2- With the POs, divide the departments into two backlog lists. Group them in a way so that the dept. that are most related to each other are bunched up. So now you have 2 backlogs.
3- POs will then re-prioritize based on what is best for the business as one entity and not on what is best for the department.
4- Divide the team. 2 devs and 2.5 devs, each will take care of one backlog.
5- If the two teams need to still know what the others do, apply scrum or scrums.
Just by doing that, you will improve the quality because devs will have a smaller scope to focus on.
1- Get the products owners (PO)/business...and let them know the situation.
2- With the POs, divide the departments into two backlog lists. Group them in a way so that the dept. that are most related to each other are bunched up. So now you have 2 backlogs.
3- POs will then re-prioritize based on what is best for the business as one entity and not on what is best for the department.
4- Divide the team. 2 devs and 2.5 devs, each will take care of one backlog.
5- If the two teams need to still know what the others do, apply scrum or scrums.
Just by doing that, you will improve the quality because devs will have a smaller scope to focus on.
Tuesday, June 7, 2011
Should technical work (non-code. Example: setting up servers, DBs, Hardware.. etc) be added as a user story to a backlog?
Short Answer; Yes
Long Answer;
A user story has 3 parts: As a [user/actor] I would like to [Action] so that [reason/value]
Whenever you make a decision, whether technical or not, you need to consider "why" we are doing what we are doing. Thus the last part of the user story has very high value to the owner. Example. why should we upgrade the server version from X to X+1. Another, Why should we increase the hard drive space from X GB to Y GB? It could be to support a new feature that will require lots of data storage or new DLLs from some server version, or lots of transactional audit data... etc. These points help put on paper in clear and concise way why we are doing a change
If you recall in scrum, during the iteration planning, we need to estimate how much effort is needed for a task. We estimate using points. Based on that you can estimate a task it takes to complete a technical or non-technical task. Remember, in scrum you estimate the effort to complete a task in full in accordance to your organization. Thus documentation, audit needs, any task required by your company would have to be considered during the iteration planning. So Hardware is a part of that. To estimate, you will need to look at the i.e. what is it that needs to be done.
Last, if you recall when working on a user story, the aim is to make it measurable. Thus you could end up with multiple stories to complete and epic story. Example: Epic. Build a server for Web application X. The stories title could be: Install OS, Install IIS or Apache, configure Ports, install DB server, Configure DB... etc. You see that you can take each of those and write a simple user story. In each case capturing a small piece of what needs to be done, and as mentioned above, capturing why we are doing it.
Long Answer;
A user story has 3 parts: As a [user/actor] I would like to [Action] so that [reason/value]
Whenever you make a decision, whether technical or not, you need to consider "why" we are doing what we are doing. Thus the last part of the user story has very high value to the owner. Example. why should we upgrade the server version from X to X+1. Another, Why should we increase the hard drive space from X GB to Y GB? It could be to support a new feature that will require lots of data storage or new DLLs from some server version, or lots of transactional audit data... etc. These points help put on paper in clear and concise way why we are doing a change
If you recall in scrum, during the iteration planning, we need to estimate how much effort is needed for a task. We estimate using points. Based on that you can estimate a task it takes to complete a technical or non-technical task. Remember, in scrum you estimate the effort to complete a task in full in accordance to your organization. Thus documentation, audit needs, any task required by your company would have to be considered during the iteration planning. So Hardware is a part of that. To estimate, you will need to look at the
Last, if you recall when working on a user story, the aim is to make it measurable. Thus you could end up with multiple stories to complete and epic story. Example: Epic. Build a server for Web application X. The stories title could be: Install OS, Install IIS or Apache, configure Ports, install DB server, Configure DB... etc. You see that you can take each of those and write a simple user story. In each case capturing a small piece of what needs to be done, and as mentioned above, capturing why we are doing it.
Subscribe to:
Posts (Atom)