I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
M. David's articles
One of the first questions I always get asked when I’m talking to someone who is new to scrum is this: Why use points to estimate the effort involved in completing a story, instead of estimating in hours or days?
Points seem arbitrary, and hard to see how they can help a team with its real-world concerns, like meeting deadlines.
Hours and days, on the other hand, can be easily understood, measured, and weighed against practical external requirements.
Additionally, one of the key rewards that gets teams interested in implementing an agile workflow is the promise that they can learn to accurately estimate the amount of work the team can do in a certain number of days or weeks. Points seems like a step back from that goal.
So why use points?
There is a practical, measurable, real-world value to using a relative estimation tool like points.
To illustrate this, let’s set up two imaginary teams–one that uses hours to estimate effort and one that uses points.
One of the first questions that comes up when a team is introduced to scrum is the difference between a sprint and a waterfall.
Traditional waterfall development happens from beginning to end in the sequence that’s easy to understand, and at first glance, agile process sprints can appear as if they’re simply shorter versions of the exact same workflow.
There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.
Respecting the differences can help your team–and the people looking on from outside of your team–get a better understanding of agile and how it works.
I’ll also point you to a few learning resources along the way, so you can take this knowledge and start exploring the potential of this powerful approach to CSS development.
What’s Wrong With Plain CSS?
But people who aren’t as enchanted with CSS as you and I have some legitimate complaints. For example, it can be difficult to keep track of the inheritance of properties across elements with differing weights and positions in a growing CSS codebase. There are no variables to support making a universal change that needs to be referenced in multiple places. And it’s often necessary to create redundant code that’s difficult to maintain just in order to make a design work consistently across different browsers.
For me, the most elegant approach to dealing with problems like these and other similar ones was created by Hampton Catlin, and open-sourced so the entire community could help it grow. I’m talking about Sass, a preprocessor for CSS that lets you write clean, maintainable, structured code that generates efficient and useful CSS.
And since Sass supports the ability to write new and original extensions, it’s much easier for developers to come up with their own enhancements. One of the ones I turn to first is a Sass library called Bourbon. While Sass provides a versatile tool set to precompile CSS, Bourbon builds on top of that with enhanced Sass functionality that makes it even faster and easier to write clean and compact code that’s easy to maintain and share.
There are several ways to get started with Sass. You can install the Ruby gem, use a development kit that includes Sass (like the Mac app, CodeKit, or take advantage of the LibSass library for native compilation performance in a language like Node or C.
Once you have Sass installed, the basic workflow is to write your CSS using the Sass language, and then compile that into regular CSS that any browser can read and understand.
The method you use to install Sass is a personal choice, and it will largely be based on your preferred development workflow and your overall skill level. Ruby is one of the most convenient ways to run Sass. I use a Mac, as I’m sure many front-end developers do, and that means I have Ruby pre-installed. So I’m going to assume you have Ruby installed and are running your commands in a terminal on your workstation. (There are excellent guides to installing and running Ruby in different environments and if you’re on Windows, you review this article to help get set up.)
Once you’re in a terminal, and you’ve verified that you have a stable release of Ruby 1.9.3 or later installed, you can issue the following command to get the Sass gem installed:[code language="shell"]
gem install sass
Then you can make sure Sass is working by issuing a version check for Sass:[code language="shell"]
This should show you that Sass is installed and running, and tell you what version you have. Anything higher than 3.3 should work just fine for this tutorial.
A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.
Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.
1. Measuring Productivity by Points
Among the most common issues that cause confusion when explaining agile is the idea that the points of effort associated with a story represent the value of that story, either in terms of business value, or in terms of objective team productivity. That kind of misunderstanding can get in the way of effective estimating.
A team cannot be compared with another by matching the points they have completed or their average velocity any more than they could be compared by looking at the size of their monitors.
One of the key advantages of adopting an agile workflow is the ability of the team to estimate new work effectively.
Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they’re going to approach stories, and how much effort each user story will take to complete.
Once a team has been working together for a while, their ability to estimate new stories becomes much better. Teams with a history of past successes and failures can compare their velocity against point estimates that everyone can agree to, and as a result they can predict with reasonable accuracy how difficult it will be for them to complete a new story.
But teams new to agile sometimes have difficulty figuring out how to estimate stories effectively.
For some, the abstract and team-specific concept of points is difficult to grasp. For others, the soft relationship between point value and actual time spent working on a story can be distracting.
Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.
Here are a few techniques that help ease teams through this phase.
These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.
Regular expressions are the ace up the sleeve of many of the most talented programmers out there. With a solid understanding of how regular expressions work, it’s sometimes possible to bypass a tangled mess of conditional logic and recursive function calls with a simple one-liner that just gets the job done much more efficiently. One […]
Agile techniques such as scrum require the attention of an agile team leader or scrum master who can run the daily standups, maintain the velocity charts, and oversee the rituals such as sprint planning meetings, retrospectives and demos.
Those duties generally belong to a member of the development team, and they do take time and attention. That means team members who take on these duties will be drawn away from their normal responsibilities.
Because of this, in companies without dedicated scrum masters, a team’s manager may be tempted to take on the responsibilities.
On the surface this may seem like a logical choice.
The manager is the one person who should be most familiar with what everybody on the team is doing. A manager may appear to be in the best position to oversee the process and evaluate whether or not scrum is being followed. In fact, many of the responsibilities of a scrum master do fall upon management in a more traditional organization.
But there is a basic conflict of interest between the duties of a manager and a scrum master.
Agile management has become increasingly popular in the tech world, in part because it addresses some of the special challenges associated with software development, such as rapid release cycles and clear open discussion of complex topics with steep learning curves. Among the most popular agile approaches is a technique called Scrum, which outlines a set of rituals, roles, and artefacts to help a team adopt an agile approach, and track its effectiveness.
One of the rituals that keeps Scrum teams working effectively is the daily standup. A daily standup gives everybody in the team the opportunity to share with the rest of the team, and anyone who cares to listen: what they’ve been working on, what they’re planning to do next, and what ‘blockers’ (or outside impediments) they may have encountered. Handled consistently, a daily standup doesn’t get in the way of productivity, and increases the transparency of the project, so everybody knows what everybody else is doing.
But it’s possible for the daily Scrum standup to become a problem. Often it can be because the team decides to break or bend some of the rules of Scrum, but just as often it can be because the team is adhering to strict practices when it comes to Scrum, but not respecting the principles behind Scrum.
A good Scrum Master should be able to pay attention to the way the team is responding to the daily standup, and watch for signals that it may be getting in the way of productivity.