Learn Software Development » Scope

Scrum – Provides you a good quick feedback on accuracy of estimates for tasks ..

ashish — Sat, 10 Dec 2011 21:24:28 +0000

One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to ensure that variables such as changes in feature specs or design between the estimate and the actual execution are eliminated; if your design changes between the initial estimate and when you sat down to do it, then it is very difficult to make such a measurement, or to learn something from such a measurement.
Consider the following example; a colleague of mine used to review the actual time spent on a task, and then compare it with the estimate for the same. He used to do this for multiple tasks, and where the variables (such as requirement changes, or design changes, etc) did not change too much during the time period, he would slowly start to learn which person tended to do the task earlier than the estimates given by the same person, and also the reverse. The next time he would ask these people for an estimate, he would accordingly make the relevant changes in the estimate he got, and then use the modified estimate for the final planning.
Scrum makes this review even more easier. In Scrum task tracking, the team is supposed to provide an update every day on what has been done, and which tasks will take up more time than initially planned. As a result, and especially because tasks tend to be defined in terms of hours and a few days rather than 5+ days, it becomes immediately clear as to which tasks are getting delayed. So, when you are using Scrum in your team, you will immediately start to see the variance between estimates and actual figures. Now, the development team may think that you are trying to find fault, but getting the estimates to be as close to actual figures is very important. This helps you better estimate the deliveries at the end of the Sprint, and prep the customer / product owner about what all is going to be delivered for which you want feedback. This also helps stakeholders get more confidence in the work done by the team.
Being able to see variance could also help you to figure out more research into why the estimates are getting varied; is it because the details provided by the Product Owner are not detailed enough to generate the right estimates, or is it because there are some design issues that cause more effort than people estimate. Make sure that this investigation is done.

The Elements of Scrum

The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper

Practical Software Metrics for Project Management and Process Improvement

How is the role of a Project Manager different from the role of Scrum Master

ashish — Sat, 09 Oct 2010 20:23:37 +0000

For teams that move from a other development methodology (such as Waterfall, Iterative, etc), the transition to moving to a Scrum based method comes with its own challenges, with one of the main challenges being the transition of roles. In the classical development methodology, the Project Manager is the person who runs the project, looking to ensure that the team is working towards its goals, and that the objectives of ensuring that the desired set of features is done (scope of the project as initially defined, is completed), within the defined cost allowed for the project, and within the desired schedule. So what happens when the team moves over to Scrum as a development methodology, and the team now has to select a ScrumMaster. The most immediate temptation is that the Project Manager takes over as the ScrumMaster; after all, this will allow the Project Manager to still drive the progress of the project and determine on a daily basis, the status of what is happening in the project.
This sounds right, but although there is no stipulation that the Project Manager cannot be the ScrumMaster, I am going to stick my neck out and recommend that the Project Manager should not be the Scrum Master, instead somebody from the team should be handling the role of the Scrum Master. Here are some differences between the role of the Scrum Master and the Project Manager:
- In Scrum, part of the role of project management (Project scheduling and tasks estimation) is distributed across the team members, with the Scrum Master there to ensure that progress is happening; this is in comparison to that of classical project management where the Project Manager is the main driver
- The Scrum meeting is not a way for the Project Manager to generate status of what is happening, it is primarily meant for the team to understand the progress that each of them is making
- The Scrum Master has a major task in terms of removing impediments that the team faces in getting their daily tasks done; something that the Project Manager would not have done at that granular level
- One of the key roles of a Scrum Master is to ensure that the team is following the Scrum principles and practices, while the classical Project Manager would have been more concerned about the schedule tracking
- The role of a Scrum Master is more of a facilitator, working with the various team members; the classical Project Manager role is more that of a driver who sets targets and others follow
- A Project Manager who has not got into the Scrum kind of way and becomes a Scrum Master is more likely to be an impediment to the team being a self-organizing responsible team, since the Scrum Master is more likely to want to lead the team and define next steps as well as targets
- The Scrum Master does not inherit the organizational roles of the Project Manager such as building the team, providing career feedback, etc; there needs to be somebody who can do this, and if the Project Manager / Scrum Master does this role as well, it makes the role of accepting the Scrum Master as a team member more difficult (you really don’t want a leader type of personality becoming a Scrum Master and seeking to rise above the team).

Engineering Practices Not Taken Care of by Scrum – Some details

ashish — Tue, 31 Aug 2010 19:07:46 +0000

Scrum never talks about engineering practices which is a good thing but this sometimes lands teams into trouble. The teams not only adopt the Scrum practices but also the principles which makes their progress sluggish and results in the code base being in a mess. This is a situation which is present in most of the cases where a failure has happened and the teams state that they have been implementing Scrum. Given that it is far easier to blame a process rather than do the necessary hard introspection, teams blame Scrum about not being able to provide engineering practices but they miss the entire point; Scrum is not about engineering practices, it’s about management. Engineering practices are whole and sole responsibility of the teams. Scrum only creates organized teams. They organize themselves, they organize their tools and they organize their engineering practices, and Scrum then opens up the entire process in terms of more information that teams have to learn to handle, and use to improve the way that they do things.
Consider some examples: The definition of Done (DoD) is defined by the development team. The criteria for done can be different for different teams; some teams might consider a piece done once the code has been reviewed others may consider is done only then functional tests are carried out and still others may call it done when the documentation is also done. It becomes necessary to keep an optimal level of done so that technical debt does not come into picture too much. And what is ‘technical debt’ ? Well, the concept of technical debt states that while adding a piece of functionality, two different approaches can be used. The first one is doing a quick job and the other one is a clean design. The quick design would mostly be messy, and one of the bigger problems is that making further changes become harder in future. So doing things in a quick and dirty way, results in technical debt which in turn requires extra effort to be put when future development is done. Doing a quick job is useful when you need to meet a deadline and can afford the extra effort later. However, you need to be sure that this is the approach you want to take, and not be surprised at the extra effort needed to be put in later.
The main difference between classical approach (Waterfall, etc) and scrum approach of development is that in scrum developers have more freedom to define level of done and amount of work to be done. They decide on the User stories to work in each of the sprint (through the estimation, although the priority comes from the Product Owner). Developers who do not use professional practices fail; but they fail independently of the processes used; blaming the processes of Scrum is convenient, but some inspection by external parties can easily reveal problems in the way that they do things.
There is sometimes a talk about too much quality being pumped into the product. Sometimes it may be a cause of concern for the owner if the team takes too much time for quality. The concept of iron triangle comes into picture here. This concepts states that Scope (features, functionalities etc.) , Resources (cost) and Schedule (time) can be considered to be three vertices of a triangle and Quality is the area enclosed by this triangle. Different groups have different priorities: users want more scope, senior management wants cut in time, financial team wants cut in budget and development team wants more quality. The end aim is to strike a balance into all the four entities. Scrum sets resources and time and lets developers decide the scope. Speed is scope/time and it’s a measure of output. If the product owner wants a higher velocity then he must work towards removing impediments; but dropping of engineering practices is not a solution. Compromise in quality is a slippery slope best avoided, and can result in so many problems later that any benefits from reducing quality are to be avoided. Consider advising a stuntman to drop safety equipment; he will never and so should be the case with developers (and even more so with the people responsible for the quality of the features and the product).

Burn Down chart and a change in scope that impacts the burn down chart

ashish — Thu, 11 Mar 2010 17:41:19 +0000

In the previous post (Burn Down Chart), we talked about what a Burn Down Chart is, and how you can use it to get the current status of the project, while not using it as a way of judging the performance of the team. This is because there are many variable that can impact the team, with one of them being changes in scope of the features that are included in the current Sprint cycle.
Typically, if you find that while viewing the burn-down chart that the amount of time available is not enough to do the required number of features / tasks pending, then there are multiple reasons that could cause this. One of the primary reasons is the changes in scope of features in the current Sprint. At the start of the Sprint cycle, when the Sprint Planning was happening, the team would have made estimates based on the user stories (and broken down tasks) defined at that time. Over the duration of the Sprint, there could be inaccuracies in estimates, but as you get a more experienced team, they get better at planning and estimating, and thus the amount of inaccuracies get reduced.
The other primary reason is changes in scope, but how do you show those on a burn-down chart, since the burn-down chart is one of the most used and primary means to determine status in Scrum. One way is to recalculate the chart based on the revised feature scope (although this would mean that the number of features you can do will reduce to account for this increase in scope). Keep an earlier version of the Burn Down chart handy since this helps in forming a sort of baseline.
Another way is to use the Burn Up Chart (refer this location) by Alistair Cockburn; where you can see progress and earned value. The burn-up project shows another line that depicts the total workload for the project, and this can be modified to show changes in scope. If there is no change in scope, then the line remains flat, but if there is an increase in scope, then it is pretty clear that there is an increase in scope, and hence, anybody viewing the graph can quickly make out the difference that the changes in scope have made to the entire project; consequently, the impact on the effort of the team and the amount of work that can be done in the remaining time.
Another thing that the ScrumMaster can do is to take a note of the changes in scope for the tasks as these changes become clear; Scrum is geared towards being as Agile as possible, but in the retrospective, it is always good to review these changes in scope to see which ones are coming because of changing requirements, and which ones are coming because of items that could have been clear earlier in the cycle (these need to be improved upon).

Introduction to Data Mining

ashish — Tue, 11 Aug 2009 18:44:02 +0000

Data mining is the process of discovering meaningful new correlations, patterns and trends by sifting through large amounts of data stored in repositories, using pattern recognition technologies as well as statistical and mathematical techniques.
Data mining is the analysis of (often large) observational data sets to find
unsuspected relationships and to summarize the data in novel ways that are
both understandable and useful to the data owner.
Data mining is an interdisciplinary field bringing together techniques from
machine learning, pattern recognition, statistics, databases, and visualization to
address the issue of information extraction from large data bases.

WHY MINE DATA ?
1. Commercial View :
– Lots of data is being collected and warehoused.
* Web data, e-commerce.
* Purchases at department/grocery stores.
* Bank/Credit Card transactions.
– Computers have become cheaper and more powerful
* Competitive Pressure is strong.
* Provide better, customized services for an edge.
2. Scientific View :
– Data collected and stored at enormous speeds(GB/hour).
* Remote sensors on a satellite.
* Telescopes scanning the skies.
* Micro arrays generating gene expression data.
* Scientific simulations generating terabytes of data.
– Traditional techniques infeasible for raw data.
– Data mining may help scientists :
* in classifying and segmenting data.
* in Hypothesis Formation.

SCOPE OF DATA MINING :
Data mining derives its name from the similarities between searching for valuable business information in a large database — for example, finding linked products in gigabytes of store scanner data — and mining a mountain for a vein of valuable ore. Both processes require either sifting through an immense amount of material, or intelligently probing it to find exactly where the value resides. Given databases of sufficient size and quality, data mining technology can generate new business opportunities by providing these capabilities:
- Automated prediction of trends and behaviors.
- Automated discovery of previously unknown patterns.

Automated discovery of previously unknown patterns.
* More columns : Analysts must often limit the number of variables they examine when doing hands-on analysis due to time constraints. Yet variables that are discarded because they seem unimportant may carry information about unknown patterns. High performance data mining allows users to explore the full depth of a database, without preselect a subset of variables.
* More rows : Larger samples yield lower estimation errors and variance, and allow users to make inferences about small but important segments of a population.