Pivotal Tracker lets you stay on top of everything to do with your project, but sometimes your stories need a little something extra.

Fortunately when some of our customers feel that way, they share the results. Here’s a roundup of recent test related Third Party Tools to help you make the most of your bugs in Tracker.

Bugherd is a website annotation tool, that lets you capture bugs, feature requests, etc.,  by clicking the offending element on your pages using BugHerd’s simple overlay. With this integration, this feedback can be sent straight to Tracker.

Bugsnag allows you to automatically create bug stories in Tracker when a crash is detected in your web and mobile applications.

HoneyBadger error management app users can link their apps to their Tracker projects. When a bug comes in, they can press a button to create a story. The bug stays linked to the story so that users can easily jump to Tracker from Honeybadger.

PivotalFeedback can be hooked up to a “Feedback” link, for example, to allow users to easily submit bugs, features, and chores to Tracker, with all the information you need.

Testrail is a test management tool for QA and software development teams. It integrates with Tracker so you can link test results to stories, push bug reports and look up the details of stories directly from TestRail.

Redline allows  anyone to point out bugs directly onto a web page without having to sign in to Tracker. Instead, their notes auto-generate a story in Tracker, along with a URL that shows the markups on the original web page.

Don’t forget to look in on the integrations we’ve created as well, including Bugzilla, Lighthouse, Jira and the ability to create connections to other tools in Tracker.

The post 6 Third Party Tools for Automatic Bug Creation and More appeared first on Pivotal Labs.

We’ve just released version 1.6.1 of the Pivotal Tracker iOS app, which includes fixes for a number of text input problems.

Most importantly, it fixes Romaji input for Japanese users. While we don’t officially support non-English localizations, we try our best to allow Tracker to be used in any language. This release also fixes a similar bug that prevented auto-completion, spell-checking, and text shortcuts from working in text fields.

Dragging stories is also snappier in this release, because we’ve reduced the delay before beginning a drag. To recap, stories can be dragged to a new location by touching and holding a story for a short time with one finger. We include a momentary delay, otherwise stories would get moved while scrolling through story panels. Touching a story with two fingers will immediately begin dragging a story, which I find really convenient and useful on an iPad.

The new version can be downloaded from the App Store, and we welcome your feedback in the Pivotal Tracker community forum.

The post Pivotal Tracker for iOS 1.6.1 fixes Romaji and other text input issues: 失礼しました｡ appeared first on Pivotal Labs.

As we recently wrote, 2013 will see major improvements to Pivotal Tracker, on a rebuilt foundation (including a brand new API), followed by major new features and an updated design.

We can’t wait to get all this into your hands quickly, and continuously improve Tracker based on your feedback. As we all know, though, making web applications work well in all of the web browsers out there can be extremely time consuming, even impossible in some cases. In order to focus our energy on product improvements, and take advantage of modern open source technologies, we will be limiting “official” support to recently released versions of the most commonly used web browsers, specifically:

• Google Chrome (version 22 and above)
• Mozilla Firefox (version 17 and above)
• Apple Safari (version 6)
• Internet Explorer (version 9 and 10)

The good news is that most of you are already using these modern browsers.

Tracker will likely work reasonably well in other types of browsers, or older versions of the above, but you will soon see an unsupported browser warning in Tracker, and may run into issues, including slower performance. Hopefully upgrading to one of the supported browsers above is not too much of an inconvenience.

If you’re limited to using an on older version of Internet Explorer, we recommend installing the Google Chrome Frame plugin, for much better compatibility with modern sites and web applications.

We will be gradually rolling out under-the-hood modernizations over the next few weeks, and getting started on the first batch of new features. Stay tuned!

The post Browser support in Pivotal Tracker appeared first on Pivotal Labs.

Tracker Tracker is an open source web app that allows you to see and work with stories from across multiple projects in one Kanban style view, with search and filtering. That’s huge. We have nothing else to say on the matter really. For anyone juggling multiple projects in Pivotal Tracker this is a must consider app.

On a side note, rumor has it Tracker Tracker was built to prevent a team’s possible migration to another tool. We’re literally speechless when our community does stuff like this, but not so tongue tied we can’t say thank you!

Here are just a few of the cool features and benefits we’ve lifted directly from the Tracker Tracker github page:

• Simultaneously view and manage stories across multiple projects
• Scrum-like UI displays one column per story state
• Search across all projects simultaneously
• All labels for all projects are visible and have epic-like mini progress charts
• Columns can be rearranged
• Labels, searches, column order, selected projects all survive browser restart
• It’s pretty easy to write custom columns and filters
• Forecasting charts

 

The post Tracker Ecosystem: Tracker Tracker – cross project visibility and panel customization appeared first on Pivotal Labs.

Today we’ve released Pivotal Tracker for iOS 1.6 to the App Store. With this release we’ve thoroughly refined the app to make updating stories easier and more enjoyable. While there are all kinds of refinements, we think you’ll be most excited about the following:

All text can now be edited inline

A story’s name, description, tasks, and comments are all editable inline, without transitioning to a new screen and losing context. While editing, text now wraps gracefully across multiple lines as you type.

For example, previous versions of the app provided a separate screen for creating a comment. In version 1.6 this now happens inline, right where the comment will be added. This allows you to continue to scan other comments or details about the story as you write.

Managing labels is easier

Finding and adding labels to a story is much improved, especially for larger projects. The label list now filters as you type, which helps avoid duplicate or mistyped labels. Adding a new label is also much more obvious and easy.

Moving Tasks doesn’t require a separate mode anymore

All tasks can now be moved using the standard move controls, without the need to go into “move” mode. This gets rid of a needless extra taps. To remove a task, simply swipe it and tap the “Delete” button.

Moving or Deleting a story are both more accessible

We’ve gotten rid of the separate “Action” screen, and replaced it with a pair of buttons to move or delete a story. You’ll find these at the very bottom of the story editor, rather than the old icon in the title bar.

We hope you love this release! Please don’t be shy about letting us know in our community about how we can continue to make the app better.

The post Greatly Refined Story Editing in Pivotal Tracker for iOS 1.6 appeared first on Pivotal Labs.

Volatility is what Pivotal Tracker uses to measure the consistency of your team’s work output. You can use that number to help you estimate the first approximation to answer the eternal question, “Will I make the deadline?”

One fine day at the office…

You’ve scoped out 100 points worth of stories for the Next Big Release™. Pivotal Tracker shows your velocity is 10 points per week. Your annual review is in 3 months and on-time delivery of this high profile project will figure prominently.

Then the CEO walks over to your desk and asks, “Will I make the launch date, 10 weeks from now?”

What do you say?

1. “Yes, my lord. Of course we’ll make our date! I’m 100% certain of it; Behold; Tracker says we’ll finish in 10 parsecs.”
2. “Probably; We had some iterations that cleared 30 points, but last week we were working on bugs and only accepted 2 points. A couple weeks of those and we might miss the deadline.”
3. “There’s no clear answer. There are so many other uncertainties, technical debt, QA, deployment work.”

It’s a trap!

Hopefully, you answered with “none of the above.” Velocity is just one measure of how your project is performing. Staking your career on it would be foolhardy. The second answer is honest, yet hopelessly vague. The third reply is why many people still think Agile is a way to duck your responsibilities as a software professional. There is hope, however; We can use Pivotal Tracker’s tools to make a better (albeit imperfect) estimate.

Past Performance is No Guarantee of Future Returns, but Yesterday’s Weather is Often Good Enough

Velocity, week over week, varies; sometimes a lot, sometimes a little. It depends on the project. Ideally, each iteration would have the same mix of stories, bugs and chores and Velocity would be very consistent. Steady velocity is a good thing™. In the real world, however, all sorts of things crop up; Your head-count goes up (or down), business priorities shift (or pivot), deferred technical debt demands payment, quality assurance files a slew of bug reports, user testing reveals flaws in product, visual design changes. The real world creates volatility in your Velocity.

A simple measure of this is standard deviation, which Tracker constantly computes for your project. Using that metric, you can decide what you should watch or change in order to meet your goals. Let’s go back to our example and look at the velocity charts in Tracker.

Assuming that we have a normal distribution of weekly velocities, the first sigma (±35%) will fall into the range of 10±3.5 points each week. That is, there is a 70% probability that your project will deliver all 100 points somewhere between 8 and 16 weeks. Why so much spread? 40% volatility is a big number! In the worst case scenario, where every iteration delivers only 6.5 points, it gets you to your goal in 100 ÷ 6.5 ≅ 16 weeks.

I Find Your Lack of Faith Disturbing

By now, you’ve had your meeting with the CEO. You’ve shown him the stories left in the backlog, the volatility of the project, and the range of estimates for delivery. This is the beginning of a conversation. If you’re team is not comfortable with the worst case scenario, something must change and, really, you have only two choices; you can reduce volatility or you can reduce scope. You will probably need to do both. Alas, there is no simple formula here. This is where skill, experience and insight will come into play. Here are some suggestions:

Reduce Volatility

• It’s critical that stories are accepted as soon as possible after they are delivered. Is the project manager unable to accept stores as they are delivered, so they don’t get credited in the iteration where they started? You can backdate acceptance to reflect when the stories were ready (rather than when the PM accepted them), but it is not something I would do on a regular basis.
• Are the stories marked as bugs and chores *truly* overhead, or are they “stealth” features? Does the story add business value to the product? That’s a feature. Flaws introduced by feature stories are bugs. Design changes surfaced by testing is a new feature.
• Are there too many stories in flight? Can you deliver stories more reliably by starting fewer at a time? Study after study shows that human beings do not multitask well at all. Do one thing, do it well, then move on.
• Are there blocked tracks? Do stories get stalled because of dependencies? Can you reorganize your backlog so each story is independent.
• Are there outside resources, out of your control, that are introducing volatility?
• Multiple rejected stories are toxic. If your team is getting more than one or two rejects each week, this may be a sign that your stories are not accurately representing what your product manager intended. It’s time to look at your work flow to prevent them from happening so often.
• Are you not refactoring enough? Constant, steady refactoring, delivered during each story is much better than giant refactors that last a week. You should consider refactoring as critical to your process and something to do “later, when you have more time for it.”
• Make all of your projects small by breaking them up. Delivering a project on time is always tricky business. I’ve discovered that it is actually easier to work on projects with short time-lines (6 weeks seems to be a good number). Urgency and a looming dead-line focuses the mind in wonderful ways.
• As a tactical measure, simplify your pointing strategy. Pivotal Tracker offers many pointing “styles;” linear, quadratic, fibonacci, or you can customize your own. Try going simpler (instead of finer granularity); a 0-1-2-3 scale (easy, medium and hard), might give you a more accurate picture.

Reduce Scope

• What’s really at risk if you miss the deadline? Often, the perceived urgency is far greater than the actual risk to the project.
• Are there features that you can jettison?
• Are there features that you can defer?
• Are you spending too much time on “pixel-perfect fidelity?” Talk to your designers; look for ways to reduce complexity. One good way to reduce complexity is to lean more heavily on standard user interface libraries (which might affect the unique visual design of the project).
• Can you make “soft releases” where you deliver fewer features, earlier, to reduce risk?
• Look at your project goals again. Are the stories in the backlog truly delivering features that will meet your goals?
• Are there parallel “tracks” that allow you to add man-power to the project (but see below).

Watch for Icebergs

• Do you need to stand up a new production environment? That will take time. It’s a point-able story. Make sure that all the necessary steps to release are in the budget.
• Are you refactoring as you go? Have you been postponing technical debt? Those interest payments will start to pile up as you get closer to release time. Make sure you and your team know that keeping the code clean is an essential part of every story.
• Anything that changes your team will change both Volatility *and* Velocity. Are you adding a new team member? (Remember Brook’s Law, “adding manpower to a late software project makes it later.”) Vacations, holidays, sick days and babies will affect your velocity. Remember to account for it in Tracker.

You’re all clear, kid, now let’s blow this thing and go home!

This article should give you a lot to think about. Good project management is hard work. When projects are just getting started, everything feels fine, and later you start to wonder when everything went to hell. Remember, volatility kills.

Notes

velocity

Just like a speedometer that measures how fast you’re hurtling through space, Tracker’s velocity is a measurement of how fast your team completes stories. Instead of miles or kilometers per hour, Tracker expresses velocity as the number of points completed per iteration (normally a week).Because Tracker stories are assigned point values instead of due dates, Tracker calculates velocity by averaging the number of points you’ve completed over the past few iterations. In Tracker, past predicts future.

volatility

Mathematically, Volatility isStandard Deviation ÷ Mean Velocity

acceptance

If stories languish in the accept/reject state (a field of red and green buttons in the backlog is a strong indicator), several bad things may happen to your project: You lose the fast feedback loop between delivery and deployment. Developers will move on to the next story and may have already lost “context” about past ones. Unaccepted stories can not be deployed, so there’s less and later feedback about the feature in the full project.

stories

What makes a feature or a bug or a chore is worthy of an entire article on its own.

The post It’s The Volatility That Will Kill You appeared first on Pivotal Labs.

January has gone by quickly! Hopefully the new year is already off to a great start for you and your entire team. I’d like to share what we’ve been up to recently, and give you a preview of what to expect in 2013.

The Big Picture

To put our plans in context, it’s important to understand our ultimate goal. We want Pivotal Tracker to be a fun, yet indispensable and transformative tool for software development teams everywhere; from the startup next door to the global enterprise, for small single backlog teams as well as larger, multi-team projects.

We believe we’re on the right path. In the last 8 years Tracker has grown organically to over 500K users around the globe, and is now an integral part of a thriving and growing software development ecosystem. But this goal is no small task for an app that began as an internal tool and an exercise in learning a promising new web development framework at the time – Ruby on Rails. So instead of simply charging ahead and piling on feature after feature we took a hard look at ourselves and acknowledged that we had accumulated a certain amount of “drag” and decided to make some long term, foundational investments.

Slimmer, Faster

Our first mission – modernize things under the hood. Last year we undertook a complete, but very focused rewrite of the Tracker web application, using modern, slimmer Javascript patterns and frameworks (including Backbone.js), exclusively against a brand new public API. Not only will this “refresh” lead to easier and faster feature development, we now also have a new, richer, REST-ier API, laying the groundwork for other great Tracker clients (on other platforms, for example).

This took some time, but the good news is, we’re almost done and have already started rolling it out to some of our projects here at Pivotal Labs. While you may notice some minor UI improvements and polish when it’s rolled out fully, it will be the same Tracker you already know, but on a better foundation, ready for the future. And shortly after, we’ll be opening up that brand new API, with more endpoints, support for epics, fine-grained access to all project activity, JSON, cross-origin resource sharing support, improved webhooks, much better documentation, even an interactive console!

New Design, New Features

While all this has been going on, we’ve been busy planning the main attraction, a redesigned “next generation” of Pivotal Tracker, to be rolled out gradually over the course of 2013, starting with some long-awaited features including story following, historical project analytics, and improved icebox management. In addition, we’re looking to improve how you collaborate and plan in Tracker with features like better search and filtering, in-app notifications, cross-project visibility, new integrations, and more.

While we’re not quite ready to share details yet, the next generation of Tracker will be a major step forward in terms of overall usability, and help your teams with the various challenges that arise as projects grow beyond a single backlog.

We’ve got a number of other things in the works for 2013, for example a shiny and more organized directory of 3rd party tools and extensions for Tracker, as well as special programs for consultancies and universities. Stay tuned for more news, including information about the new API and how to request early access to the Tracker next-generation beta. If you’re not already, please follow us on Twitter, and like us on Facebook!

 

 

 

 

 

The post 2013 Tracker Update – New Features, New API, New Design appeared first on Pivotal Labs.

With all these APIs floating around don’t you sometimes wish that apps would just talk to each other and keep us humans out of it. We’re not there yet, but we’re getting close with CloudWork.

It’s so straightforward I feel it’s something the Hulk might say – “Cloud Work!, Hulk no Smash puny keyboard”. If I were to use more than a noun and a verb to describe it, CloudWork connects apps via their APIs to help automate business processes. Yeah, I prefer the Hulk version. Also it doesn’t require any programming knowledge to use it (yes, there are people that read this blog that can’t code).

RIght now they connect Pivotal Tracker with Toggl, Google Calendar, Evernote, Zendesk and desk.com. I’m sure if you ask them to link to something else they’ll get to it pretty fast. They’re a cool team that is pretty on the ball. Please give it a try and tell us what you think.

The post Tracker Ecosystem: CloudWork – Making cloud apps work together better appeared first on Pivotal Labs.

Sandy Walsh, a developer at Rackspace who also works on the OpenStack cloud development project, has written a blog post asserting that Iterations and Time-boxing are (Mostly) Useless. While I enjoy Sandy’s thought provoking content, I feel compelled to respond with some alternative points of view, as my company is currently providing Scrum-centric Agile coaching services to Rackspace. I’ve also enjoyed working directly with J.B. Rainsberger, who commented on Sandy’s post, as a Board member of the Agile Alliance, and suggest that JB makes many fine comments. You can also see Glen Campbell’s post as a reply to Sandy here. Given that I like to write, I hope you find a lot of value in this rather long post.
Agile and Code Management
Let’s handle the easiest item that Sandy addresses – code management. Sandy correctly points out that Agile and Kanban stress traditional code management practices and that modern code management tools help enable agility. Yup. Just like we’ve always known that test automation is a good thing, but we’re starting to see a lot more of it because of better test automation frameworks (aka tools).
XP, Agile, and Experience
XP is the Agile method that plays best to highly accomplished, experienced developers. To understand why, we need to understand what a cognitive psychologist means when we say that someone has “experience”. We mean that this person has a deep, thorough, and accurate cognitive library of stereotypical plans (you can think of a cognitive plan as similar to a software pattern) that they can use to efficiently and competently solve complex problems.

Expertise, therefore, is the ability to “know” the “right” way to solve a problem because you’ve solved this or similar problems many times before. It is this notion of “expertise” that cause individual “expert” developers to complain loudly when asked to decompose backlog items into 3hr or less tasks in a Sprint planning meeting -  “Dangit – I just know how to get this done – why do I have to task it out?” In reality, experts do know how to get these things done, and task-decomposition can be really painful (this is a well-known problem in knowledge engineering; the greater the expertise, the harder it is for the expert to explicate their cognitive library).

The reality, however, is that most development teams are composed not of superstar experts, but of a mix of people with different skills and experiences. As such, the Sprint planning process of decomposing backlog items into 3hr (my target recommendation) task helps ensure that thorough planning is accomplished (as JB recommends), enables the team to work as a team (because tasks can be done by various individuals within the team), and increases confidence that the team will accomplish their work as a team with measurable progress.

You can find a detailed discussion of cognitive libraries and the interesting effects of different levels of expertise in Chapter 1 of my book “Journey of the Software Professional”. As I said earlier, of all the Agile methods, XP is the method that plays most to experience, and that the greater the experience of the development team, the more likely that they will gravitate towards efficient execution of XP practices.

I’ve coached mature Agile teams who have earned the right to simple decompose tasks without hour-based estimates, because they’ve proven that their tasks are such that reliable progress can be made. This proof is that when they plan for a task to be accomplished within a day… it is. Over time, this becomes a very powerful habit – learning to plan so that more often than note, teams can move tasks from “work-in-progress” to “done” and from “to-do” to “work-in-progress” every day. However, I do believe that this is something a team must earn, and until they’re reliably creating and delivering against small tasks, they should be doing hours based estimates.
I Don’t Want “Command and Control” (Unless I’m Commanding and Controlling)
I find arguments from developers against fine-grained task decomposition very interesting. One hand, most developers dislike being told by management what they should be doing. This aspect of a self-managed team – that the team chooses how tasks are consumed – is one of the single most liberating aspects of Scrum-based Agile. And yet, in the same conversation, these developers often rail against detailed task decomposition because they “know” who is going to do the task.

Huh?

Let’s get this straight. The Sprint planning process is pretty straightforward: The team decomposes tasks into the work that needs to be done. The team chooses who works on the tasks. If the team chooses to have one person do the bulk of the decomposition of a single user story – then great – do it. If the team chooses to have one person do the bulk – or even all – of the tasks associated with a backlog item – then great.

I can’t put my finger on why this concept appears to challenging to some of the teams I’ve coached.

This is, however, a lot more to this story. If you’re really motivated to create high performing teams, read on.
Team Performance and Shared Transactional Memory
A team that chooses to forego fine-grained task decomposition is also choosing to forego an amazing opportunity to create a higher performance team. I discuss this extensively in chapter 7 of Journey of the Software Professional, so here are some highlights. (See also What’s Collaboration and Some Answers to “What’s Collaboration?”).

I’d like to specifically focus on an important aspect of team performance based on something referred to as a collective mind or a shared transactional memory. Here is how I described it more than 25 years ago – a description I believe is still valid today.

Suppose you are comparing two teams, Team A, and Team B. Team A is obviously more effective than Team B. The question is “Why?” Lots of potential variables come to mind. Team A might have better tools, a better working environment, more experienced developers, and so forth. But what if you could hold all these variables equal? What could now cause Team A to be more effective than Team B?The answer lies in how the members of Team A have molded their collective experience into a sum greater than the parts. Somehow, Team A is more effective when working together than when working apart. But how can this happen?Think about some of your earliest interactions with your colleagues. What did you know about them when you first met? What do you know about them now? As we work together, we learn about each other. We learn Jill is an excellent analyst, Raji is a great designer, and Ruth is a powerful motivator. The team forms a collective mind, in which the interdependent actions of the team create a “a separate transactional memory system, complete with differentiated responsibility for remembering different portions of common experience” [Weick 1993]. More plainly, we not only know Jill is an excellent analyst, we rely on our knowledge of Jill being an excellent analyst, and begin to assign her tasks capitalizing on her skills. We remember the tasks she has been given, and rely on her memory when we need information about those tasks. A collective mind enables the team to become more effective in problem solving precisely because each member of the team can rely on other members to provide experience and skills we do not possess as individuals.Conversely, just because the raw potential of the team exceeds the individual does not mean it will be realized. There are times when a team can perform much worse than any single individual. One way this happens is when teams fail to account for their own poor performance. Instead of working to identify what is wrong and fix it, effort is spent identifying other groups that can “take the blame” [Kahn 1995]. Another way this can happen is through groupthink. Groupthink occurs when each member of the team stops critically examining decisions in order to make them better. Instead, effort is spent finding ways to justify a poor decision [Janis 1971]. Collective mind and groupthink represent two extremes: one optimal and the other to be avoided at all costs.What are the implications of collective mind? First, the potential of each team is unique, initially based on the individual ability of each team member. When harnessed, this can produce incredible performance, as when the Macintosh team created the first Macintosh or when the Chicago Bulls won three NBA championships in a row. Second, individual talents alone do not imply success. A collective mind is based on the collective skills and experience of the team. No matter how good the star, he or she needs a supporting cast. Third, a collective mind can only be formed as the result of interactions among team members. This process takes time. How long did it take the Bulls to win their first NBA championship, even with Michael Jordan leading the team? Fourth, a collective mind is a fragile thing, easily lost and not easily recreated. Did the Bulls immediately win the title when Michael Jordan returned to the team in 1995? Finally, because team members rely on each other for information, skills, experience, and ability, changing the composition of the team can have substantial repercussions.Note: Send me an email if you want the references cited above.

The alert reader will see the implications of Sprint task decomposition in helping form high-performing teams: It helps form the collective mind. And it keeps this mind fresh, because team members can choose to perform different tasks.
Some Thoughts on Estimating
My experience with estimating is that estimating large, poorly specified, inter-dependent backlog items is very hard. That’s different than saying we estimate future things more poorly.That’s why agilists like backlog items that follow Bill Wake’s acronym INVEST. The “S” means that the backlog items are “small enough” to be estimated. More generally, humans are better at estimating smaller things more accurately than larger things, and we’re better at estimating things within our experience base (cognitive library) than outside our experience base. Which is why we lean heavily on the people who own the backlog to create “small” backlog items. Which is also hard, because customers want big chunky innovative things that make your product awesome, but to create these big things in a reliable manner, we need to decompose them into smaller things. Sandy recommends 1-3 days, which is fine, but I suspect that Sandy would agree that Innovation with a capital “I” doesn’t happen in 1-3 days. That’s OK – but it means that we have to have different levels of estimating to serve the needs of the business. I recommend three levels of estimates: shirt sizes, points, and hours. Here is how I like to use them.

Shirt sizes are created by one or two trusted senior technical leaders for roadmap items, “epics”, and backlog items. While these items don’t typically meet requirements of the INVEST acronym, shirt sizes, as non-binding estimates of time become invaluable tools for product managers and product owners to understand the implications of certain business decisions.

Since Sandy references Barry Boehm’s spiral method, I’m guessing that Sandy is also familiar with Wide-Band Delphi as an estimating practice. Points-based estimates are just wide-band delphi, repackaged with a bit of fun.

We use points based estimates as the next level of estimates of the amount of work that the team expects that they need to do to complete all of the backlog items that they business believes is required to release software to customers. It is a way to provide a more accurate schedule estimate than a WAG, because by tracking work-completed-per-unit-of-time, we can create a velocity. Mike Cohn does a good job of explaining this in his many varied writings. And yes, items that are subjected to points-based estimates should indeed follow the INVEST acronym, which is part of the art of Agile Product Management – learning to “split” large, innovative, market-changing roadmap items into collections of small, INVESTable, Sprint-items. Of course, Scrum isn’t new in this regard – task decomposition is a fundamental activity in any project regardless of method.

Wide-Band Delphi has other benefits. It helps teams feel like, well, teams, because they were involved as a team in creating the estimates. It provides an opportunity for significant organizational learning as various team members clarify their understanding of the backlog item being estimated. And it provides real-time opportunities to have critical conversations about the story before work begins.

Lastly, we use hours when planning a Sprint to provide confidence that the specific backlog items undertaken for the Sprint have a high degree of confidence in completing by the end of the sprint. This is tracked in the “burn down”, and is useful for “early warning” during the Sprint. This may not be needed in a Kanban-style model, but I’m in agreement with JB – through tasking of a story helps ensure it is completed effectively.

Of course, we agree on the value of responding to change rather than following a plan. But we still plan. At the roadmap, release, and Sprint.
What About End of Sprint Waste?
Sandy expresses what appears to be grave concern over the potential for “waste” at the end of the Sprint. In nearly a decade of coaching Agile teams, I’ve never seen a team consistently have “waste” at the end of the Sprint. Here’s why. A Scrum team that engages in release planning will have, as Sandy illustrated, created a release plan based on a number of Sprints and the expected number of stories – points – they will complete in each Sprint. Let’s say that in Sprint one the team estimates that they’ll deliver between 25 and 35 points. It is, after all, their first sprint, so they have no historical data on their own performance. Let’s assume the team agrees to tackle 29 points and at the end of Sprint one they complete all 29 points and have time left over.

First, this team should be celebrating. They delivered “Done, Done” work within their estimated velocity. This is outstanding.

Every team I’ve coached will adjust their plan for Sprint two and pull in additional backlog items. So, will the original plan for Sprint two might have been another 29 points, the adjusted plan for Sprint two will have something like 33 points. Note that the team still hasn’t adjusted their estimated range of points – they have no data that suggests they’re off.

This process continues until the team reaches a reasonable number of points that they can consume on a regular basis. If they increase their performance because of thorough planning or just better development, then they’ll gradually raise their range of estimated points – perhaps from 25 to 35 points / Sprint to something like 35 – 45 points / Sprint. That’s a marvelous improvement, and ultimately, increase team velocity is everyone’s job.It won’t result in indefinite waste in every Scrum cycle because the team is adjusting their work based on the reality of what they’re delivering.

And, for the record, I feel that Sandy is (perhaps inadvertently) painting a somewhat optimistic picture of Scrum teams. Most Scrum teams, especially those who are new to Scrum, underestimate how hard it can be to get a backlog item to “Done, Done”. They don’t usually have free work at the end of the Sprint. Instead, they’re hustling to meet their commitments, and usually downgrading the number of points in the next Sprint.

And on those rare occasions when a team does have a bit of extra time in their Sprint I am completely comfortable letting them decide how to spend it. (See also: Entropy Reduction and Sustainable Agile Development).
Predicting the Future – Always A Challenge!
I appreciate that Sandy has a sensitivity to helping provide an estimate of when the team will be finished. He correctly identifies the realistic needs for business to understand this. However, his solution will only really work for certain contexts, and we need other solutions for other contexts.

One context is a Silicon-Valley software startup like The Innovation Games Company. We make a fantastic brand engagement platform called Knowsy. And we often operate more like the Kanban model that Sandy espouses than the typical Scrum multi-sprint release model I usually teach to my enterprise clients. That make sense – we’re not yet driven by market forces and we’re a small, co-located team. We release software when we’re ready. And we have zero complex team coordination issues. So, we release when we’re ready.

Most enterprise / business software, however, doesn’t fit this context. As Sandy points out, there are complex, inter-related dependencies with other teams. And these teams need to move from “How fast can you ship this?” to “When should we ship this to maximize our profit”? Note that the former is a question usually driven by product teams who are unclear of the market events and market rhythms of the market segments they’re serving, while the latter question is driven by product teams who understand when it is most advantageous to ship bits. In these cases, a release plan, which I define as a the expected number of Sprints required to consume the number of required backlog items to create enough business value to motivate the release, is a critical component of the overall product development process.

Release planning is hard work, and I find that teams who have enjoyed the benefits of running a few Sprints and have a sense of “Done, Done” typically do a better job. Of course, that’s not a requirement, because estimating effort using Wide-Band Delphi doesn’t require a team having Sprint experience. It is just nice, and that’s why we try to sequence transition projects by having teams get good at Sprinting before being expected to develop a release plan. Regardless, release planning is a grand tradition in Agile (re-read the Agile Manifesto if you’re not sure).

All of this said, it is important that we, as a global community, continue to experiment with ways to estimate the future. One area that I consider promising, but have not formally explored with any client, is the use of a prediction market. Microsoft, for example, has reported some success with prediction markets (see, for example, this rather dated article from Business Week). In my ideal world, I’d like to compare a prediction market model with the release planning process I advocate to see if there is convergence. In both cases, I suspect that as the items in the release become more INVESTable the accuracy of both the release plan and the prediction market will increase. But maybe I’m wrong. Maybe the key to getting actionable estimates on relatively imprecisely specified work is through a prediction market.

Lastly, I want to recognize that there other approaches to estimating. Function points, for example, is based on mapping new work to a known standard, and is certainly appropriate in certain contexts. However, function points is often too slow for relatively small, fast-moving Agile teams, and, since I’m not qualified to use it, I don’t.
Are You Optimizing for Individual or Organizational Efficiency?
This is not an easy question. Before jumping to any conclusions, I ask you to consider the nature of the organization that is creating the code and the responsibility that this organization has to its respective constituents. Brooks pointed out ages ago in The Mythical Man-Month that a small team is dramatically more productive on a per-person basis than a large team. But you couldn’t create the OS 360 with a 9-person team, and companies like Rackspace can’t create new industries and amazing products like Cloud Servers of Cloud Files without large groups of developers.

So, yes, I’ll readily admit that any process that deals with macro planning and multi-team coordination will introduce a certain degree of process overhead that detracts from “writing code”. All of my clients know that I recommend that they create 2-3 year roadmaps, representations of system architectures, and diagrams of system / team dependencies. All of these are not “writing code” and all of them, to some level, introduce a level of managerial overhead. And while we seek to keep these to a minimum, we do them because the coordination of large groups of people require certain forms of managerial overhead.

I’ll conclude by answering Sandy’s actual questions:
Sandy’s Question: “What do you think? Would your daily development process be better if you didn’t have to break down tasks to super-fine resolution?”
Luke’s Answer: It depends on the nature of the task. If you’re asking me to “go solo” and work alone in tackling a backlog item that is within my cognitive library and one that I’ve proven that I can successfully perform multiple times in the past, then, no, my personal daily development process will not be more efficient with a “super-fine” resolution task decomposition. However, if you’re asking me to tackle a backlog item that is new, or to work with a team that may not have a reasonably similar cognitive library as my own, or honor the idea that a Scrum team chooses which team member(s) will work on tasks, then yes my team will be more efficient with a “super-fine” resolution task decomposition, where super-fine is defined as tasks with a 3hr or less estimate.
Sandy’s Question: “As a manager, could you better estimate ability-to-deliver based on higher-level sentiment vs. tasks completed?”
No. The best way to estimate future ability-to-deliver future work is similarly sized actual work completed by the team doing the work. Teams who undertake serious and thorough wide-band delphi estimation and then rigorously track their work to a consistent standard of “Done, Done” create the best “ability-to-deliver” estimates. (See Jeff Sutherland’s excellent data on such teams).
Sandy, thanks for giving the global community something good to discuss.

Sandy Walsh, a developer at Rackspace who also works on the OpenStack cloud development project, has written a blog post asserting that Iterations and Time-boxing are (Mostly) Useless. While I enjoy Sandy’s thought provoking content, I feel compelled to respond with some alternative points of view, as my company is currently providing Scrum-centric Agile coaching services to Rackspace. I’ve also enjoyed working directly with J.B. Rainsberger, who commented on Sandy’s post, as a Board member of the Agile Alliance, and suggest that JB makes many fine comments. You can also see Glen Campbell’s post as a reply to Sandy here. Given that I like to write, I hope you find a lot of value in this rather long post.
Agile and Code Management
Let’s handle the easiest item that Sandy addresses – code management. Sandy correctly points out that Agile and Kanban stress traditional code management practices and that modern code management tools help enable agility. Yup. Just like we’ve always known that test automation is a good thing, but we’re starting to see a lot more of it because of better test automation frameworks (aka tools).
XP, Agile, and Experience
XP is the Agile method that plays best to highly accomplished, experienced developers. To understand why, we need to understand what a cognitive psychologist means when we say that someone has “experience”. We mean that this person has a deep, thorough, and accurate cognitive library of stereotypical plans (you can think of a cognitive plan as similar to a software pattern) that they can use to efficiently and competently solve complex problems.

Expertise, therefore, is the ability to “know” the “right” way to solve a problem because you’ve solved this or similar problems many times before. It is this notion of “expertise” that cause individual “expert” developers to complain loudly when asked to decompose backlog items into 3hr or less tasks in a Sprint planning meeting -  “Dangit – I just know how to get this done – why do I have to task it out?” In reality, experts do know how to get these things done, and task-decomposition can be really painful (this is a well-known problem in knowledge engineering; the greater the expertise, the harder it is for the expert to explicate their cognitive library).

The reality, however, is that most development teams are composed not of superstar experts, but of a mix of people with different skills and experiences. As such, the Sprint planning process of decomposing backlog items into 3hr (my target recommendation) task helps ensure that thorough planning is accomplished (as JB recommends), enables the team to work as a team (because tasks can be done by various individuals within the team), and increases confidence that the team will accomplish their work as a team with measurable progress.

You can find a detailed discussion of cognitive libraries and the interesting effects of different levels of expertise in Chapter 1 of my book “Journey of the Software Professional”. As I said earlier, of all the Agile methods, XP is the method that plays most to experience, and that the greater the experience of the development team, the more likely that they will gravitate towards efficient execution of XP practices.

I’ve coached mature Agile teams who have earned the right to simple decompose tasks without hour-based estimates, because they’ve proven that their tasks are such that reliable progress can be made. This proof is that when they plan for a task to be accomplished within a day… it is. Over time, this becomes a very powerful habit – learning to plan so that more often than note, teams can move tasks from “work-in-progress” to “done” and from “to-do” to “work-in-progress” every day. However, I do believe that this is something a team must earn, and until they’re reliably creating and delivering against small tasks, they should be doing hours based estimates.
I Don’t Want “Command and Control” (Unless I’m Commanding and Controlling)
I find arguments from developers against fine-grained task decomposition very interesting. One hand, most developers dislike being told by management what they should be doing. This aspect of a self-managed team – that the team chooses how tasks are consumed – is one of the single most liberating aspects of Scrum-based Agile. And yet, in the same conversation, these developers often rail against detailed task decomposition because they “know” who is going to do the task.

Huh?

Let’s get this straight. The Sprint planning process is pretty straightforward: The team decomposes tasks into the work that needs to be done. The team chooses who works on the tasks. If the team chooses to have one person do the bulk of the decomposition of a single user story – then great – do it. If the team chooses to have one person do the bulk – or even all – of the tasks associated with a backlog item – then great.

I can’t put my finger on why this concept appears to challenging to some of the teams I’ve coached.

This is, however, a lot more to this story. If you’re really motivated to create high performing teams, read on.
Team Performance and Shared Transactional Memory
A team that chooses to forego fine-grained task decomposition is also choosing to forego an amazing opportunity to create a higher performance team. I discuss this extensively in chapter 7 of Journey of the Software Professional, so here are some highlights. (See also What’s Collaboration and Some Answers to “What’s Collaboration?”).

I’d like to specifically focus on an important aspect of team performance based on something referred to as a collective mind or a shared transactional memory. Here is how I described it more than 25 years ago – a description I believe is still valid today.

Suppose you are comparing two teams, Team A, and Team B. Team A is obviously more effective than Team B. The question is “Why?” Lots of potential variables come to mind. Team A might have better tools, a better working environment, more experienced developers, and so forth. But what if you could hold all these variables equal? What could now cause Team A to be more effective than Team B?The answer lies in how the members of Team A have molded their collective experience into a sum greater than the parts. Somehow, Team A is more effective when working together than when working apart. But how can this happen?Think about some of your earliest interactions with your colleagues. What did you know about them when you first met? What do you know about them now? As we work together, we learn about each other. We learn Jill is an excellent analyst, Raji is a great designer, and Ruth is a powerful motivator. The team forms a collective mind, in which the interdependent actions of the team create a “a separate transactional memory system, complete with differentiated responsibility for remembering different portions of common experience” [Weick 1993]. More plainly, we not only know Jill is an excellent analyst, we rely on our knowledge of Jill being an excellent analyst, and begin to assign her tasks capitalizing on her skills. We remember the tasks she has been given, and rely on her memory when we need information about those tasks. A collective mind enables the team to become more effective in problem solving precisely because each member of the team can rely on other members to provide experience and skills we do not possess as individuals.Conversely, just because the raw potential of the team exceeds the individual does not mean it will be realized. There are times when a team can perform much worse than any single individual. One way this happens is when teams fail to account for their own poor performance. Instead of working to identify what is wrong and fix it, effort is spent identifying other groups that can “take the blame” [Kahn 1995]. Another way this can happen is through groupthink. Groupthink occurs when each member of the team stops critically examining decisions in order to make them better. Instead, effort is spent finding ways to justify a poor decision [Janis 1971]. Collective mind and groupthink represent two extremes: one optimal and the other to be avoided at all costs.What are the implications of collective mind? First, the potential of each team is unique, initially based on the individual ability of each team member. When harnessed, this can produce incredible performance, as when the Macintosh team created the first Macintosh or when the Chicago Bulls won three NBA championships in a row. Second, individual talents alone do not imply success. A collective mind is based on the collective skills and experience of the team. No matter how good the star, he or she needs a supporting cast. Third, a collective mind can only be formed as the result of interactions among team members. This process takes time. How long did it take the Bulls to win their first NBA championship, even with Michael Jordan leading the team? Fourth, a collective mind is a fragile thing, easily lost and not easily recreated. Did the Bulls immediately win the title when Michael Jordan returned to the team in 1995? Finally, because team members rely on each other for information, skills, experience, and ability, changing the composition of the team can have substantial repercussions.Note: Send me an email if you want the references cited above.

The alert reader will see the implications of Sprint task decomposition in helping form high-performing teams: It helps form the collective mind. And it keeps this mind fresh, because team members can choose to perform different tasks.
Some Thoughts on Estimating
My experience with estimating is that estimating large, poorly specified, inter-dependent backlog items is very hard. That’s different than saying we estimate future things more poorly.That’s why agilists like backlog items that follow Bill Wake’s acronym INVEST. The “S” means that the backlog items are “small enough” to be estimated. More generally, humans are better at estimating smaller things more accurately than larger things, and we’re better at estimating things within our experience base (cognitive library) than outside our experience base. Which is why we lean heavily on the people who own the backlog to create “small” backlog items. Which is also hard, because customers want big chunky innovative things that make your product awesome, but to create these big things in a reliable manner, we need to decompose them into smaller things. Sandy recommends 1-3 days, which is fine, but I suspect that Sandy would agree that Innovation with a capital “I” doesn’t happen in 1-3 days. That’s OK – but it means that we have to have different levels of estimating to serve the needs of the business. I recommend three levels of estimates: shirt sizes, points, and hours. Here is how I like to use them.

Shirt sizes are created by one or two trusted senior technical leaders for roadmap items, “epics”, and backlog items. While these items don’t typically meet requirements of the INVEST acronym, shirt sizes, as non-binding estimates of time become invaluable tools for product managers and product owners to understand the implications of certain business decisions.

Since Sandy references Barry Boehm’s spiral method, I’m guessing that Sandy is also familiar with Wide-Band Delphi as an estimating practice. Points-based estimates are just wide-band delphi, repackaged with a bit of fun.

We use points based estimates as the next level of estimates of the amount of work that the team expects that they need to do to complete all of the backlog items that they business believes is required to release software to customers. It is a way to provide a more accurate schedule estimate than a WAG, because by tracking work-completed-per-unit-of-time, we can create a velocity. Mike Cohn does a good job of explaining this in his many varied writings. And yes, items that are subjected to points-based estimates should indeed follow the INVEST acronym, which is part of the art of Agile Product Management – learning to “split” large, innovative, market-changing roadmap items into collections of small, INVESTable, Sprint-items. Of course, Scrum isn’t new in this regard – task decomposition is a fundamental activity in any project regardless of method.

Wide-Band Delphi has other benefits. It helps teams feel like, well, teams, because they were involved as a team in creating the estimates. It provides an opportunity for significant organizational learning as various team members clarify their understanding of the backlog item being estimated. And it provides real-time opportunities to have critical conversations about the story before work begins.

Lastly, we use hours when planning a Sprint to provide confidence that the specific backlog items undertaken for the Sprint have a high degree of confidence in completing by the end of the sprint. This is tracked in the “burn down”, and is useful for “early warning” during the Sprint. This may not be needed in a Kanban-style model, but I’m in agreement with JB – through tasking of a story helps ensure it is completed effectively.

Of course, we agree on the value of responding to change rather than following a plan. But we still plan. At the roadmap, release, and Sprint.
What About End of Sprint Waste?
Sandy expresses what appears to be grave concern over the potential for “waste” at the end of the Sprint. In nearly a decade of coaching Agile teams, I’ve never seen a team consistently have “waste” at the end of the Sprint. Here’s why. A Scrum team that engages in release planning will have, as Sandy illustrated, created a release plan based on a number of Sprints and the expected number of stories – points – they will complete in each Sprint. Let’s say that in Sprint one the team estimates that they’ll deliver between 25 and 35 points. It is, after all, their first sprint, so they have no historical data on their own performance. Let’s assume the team agrees to tackle 29 points and at the end of Sprint one they complete all 29 points and have time left over.

First, this team should be celebrating. They delivered “Done, Done” work within their estimated velocity. This is outstanding.

Every team I’ve coached will adjust their plan for Sprint two and pull in additional backlog items. So, will the original plan for Sprint two might have been another 29 points, the adjusted plan for Sprint two will have something like 33 points. Note that the team still hasn’t adjusted their estimated range of points – they have no data that suggests they’re off.

This process continues until the team reaches a reasonable number of points that they can consume on a regular basis. If they increase their performance because of thorough planning or just better development, then they’ll gradually raise their range of estimated points – perhaps from 25 to 35 points / Sprint to something like 35 – 45 points / Sprint. That’s a marvelous improvement, and ultimately, increase team velocity is everyone’s job.It won’t result in indefinite waste in every Scrum cycle because the team is adjusting their work based on the reality of what they’re delivering.

And, for the record, I feel that Sandy is (perhaps inadvertently) painting a somewhat optimistic picture of Scrum teams. Most Scrum teams, especially those who are new to Scrum, underestimate how hard it can be to get a backlog item to “Done, Done”. They don’t usually have free work at the end of the Sprint. Instead, they’re hustling to meet their commitments, and usually downgrading the number of points in the next Sprint.

And on those rare occasions when a team does have a bit of extra time in their Sprint I am completely comfortable letting them decide how to spend it. (See also: Entropy Reduction and Sustainable Agile Development).
Predicting the Future – Always A Challenge!
I appreciate that Sandy has a sensitivity to helping provide an estimate of when the team will be finished. He correctly identifies the realistic needs for business to understand this. However, his solution will only really work for certain contexts, and we need other solutions for other contexts.

One context is a Silicon-Valley software startup like The Innovation Games Company. We make a fantastic brand engagement platform called Knowsy. And we often operate more like the Kanban model that Sandy espouses than the typical Scrum multi-sprint release model I usually teach to my enterprise clients. That make sense – we’re not yet driven by market forces and we’re a small, co-located team. We release software when we’re ready. And we have zero complex team coordination issues. So, we release when we’re ready.

Most enterprise / business software, however, doesn’t fit this context. As Sandy points out, there are complex, inter-related dependencies with other teams. And these teams need to move from “How fast can you ship this?” to “When should we ship this to maximize our profit”? Note that the former is a question usually driven by product teams who are unclear of the market events and market rhythms of the market segments they’re serving, while the latter question is driven by product teams who understand when it is most advantageous to ship bits. In these cases, a release plan, which I define as a the expected number of Sprints required to consume the number of required backlog items to create enough business value to motivate the release, is a critical component of the overall product development process.

Release planning is hard work, and I find that teams who have enjoyed the benefits of running a few Sprints and have a sense of “Done, Done” typically do a better job. Of course, that’s not a requirement, because estimating effort using Wide-Band Delphi doesn’t require a team having Sprint experience. It is just nice, and that’s why we try to sequence transition projects by having teams get good at Sprinting before being expected to develop a release plan. Regardless, release planning is a grand tradition in Agile (re-read the Agile Manifesto if you’re not sure).

All of this said, it is important that we, as a global community, continue to experiment with ways to estimate the future. One area that I consider promising, but have not formally explored with any client, is the use of a prediction market. Microsoft, for example, has reported some success with prediction markets (see, for example, this rather dated article from Business Week). In my ideal world, I’d like to compare a prediction market model with the release planning process I advocate to see if there is convergence. In both cases, I suspect that as the items in the release become more INVESTable the accuracy of both the release plan and the prediction market will increase. But maybe I’m wrong. Maybe the key to getting actionable estimates on relatively imprecisely specified work is through a prediction market.

Lastly, I want to recognize that there other approaches to estimating. Function points, for example, is based on mapping new work to a known standard, and is certainly appropriate in certain contexts. However, function points is often too slow for relatively small, fast-moving Agile teams, and, since I’m not qualified to use it, I don’t.
Are You Optimizing for Individual or Organizational Efficiency?
This is not an easy question. Before jumping to any conclusions, I ask you to consider the nature of the organization that is creating the code and the responsibility that this organization has to its respective constituents. Brooks pointed out ages ago in The Mythical Man-Month that a small team is dramatically more productive on a per-person basis than a large team. But you couldn’t create the OS 360 with a 9-person team, and companies like Rackspace can’t create new industries and amazing products like Cloud Servers of Cloud Files without large groups of developers.

So, yes, I’ll readily admit that any process that deals with macro planning and multi-team coordination will introduce a certain degree of process overhead that detracts from “writing code”. All of my clients know that I recommend that they create 2-3 year roadmaps, representations of system architectures, and diagrams of system / team dependencies. All of these are not “writing code” and all of them, to some level, introduce a level of managerial overhead. And while we seek to keep these to a minimum, we do them because the coordination of large groups of people require certain forms of managerial overhead.

I’ll conclude by answering Sandy’s actual questions:
Sandy’s Question: “What do you think? Would your daily development process be better if you didn’t have to break down tasks to super-fine resolution?”
Luke’s Answer: It depends on the nature of the task. If you’re asking me to “go solo” and work alone in tackling a backlog item that is within my cognitive library and one that I’ve proven that I can successfully perform multiple times in the past, then, no, my personal daily development process will not be more efficient with a “super-fine” resolution task decomposition. However, if you’re asking me to tackle a backlog item that is new, or to work with a team that may not have a reasonably similar cognitive library as my own, or honor the idea that a Scrum team chooses which team member(s) will work on tasks, then yes my team will be more efficient with a “super-fine” resolution task decomposition, where super-fine is defined as tasks with a 3hr or less estimate.
Sandy’s Question: “As a manager, could you better estimate ability-to-deliver based on higher-level sentiment vs. tasks completed?”
No. The best way to estimate future ability-to-deliver future work is similarly sized actual work completed by the team doing the work. Teams who undertake serious and thorough wide-band delphi estimation and then rigorously track their work to a consistent standard of “Done, Done” create the best “ability-to-deliver” estimates. (See Jeff Sutherland’s excellent data on such teams).
Sandy, thanks for giving the global community something good to discuss.

It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.

For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.

The Scrumy API is divided into two separate parts: REST and Webhooks.

The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.

Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.

So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at support@scrumy.com.